At the moment we mostly have `user_has_permissions` execute first. It
shouldn’t matter, but it feels right for us to check that a user is
logged in before we check their permissions to a service. Otherwise a
malicious user could (maybe) check if a service ID belongs to a real
service, and go on to do something malicious with that information.
This commit adds some extra test code to enforce that the order is
always the same.
N.B. decorators in Python execute from closest to furthest (from the
line on which the function is defined).
We accidentally miss these sometimes. This code adds a test which
inspects the code to automatically check that any function which:
- handles a route
- accepts a service_id
For each function it checks that each of these routes have the
permissions decorator we’d expect.
Most of the introspection/AST code is adapted from here:
https://mvdwoord.github.io/exploration/2017/08/18/ast_explore.html
A user might not have a guessable organisation type, even if the service
they’re working on does have an organisation set. This can happen for
users with @nhs.net email addresses, for example.
An invited user can’t be added to an organisation or service, only a
real user can. So the methods to do this should be on the user model,
and take the details of the invite as arguments.
If we’re not sure whether a user belongs to a crown organisation or not
we want to fix that before.
This is a last-ditch fallback because we shouldn’t be adding new
organisations without also setting their crown status.
This is an immediate fix to add the permission checks to the callback page.
However, we have a plan to add a unit test to check for permission introspectively for all routes that have service_id.
Utils 33.0.0 adds alt text to email branding - the HTMLEmailTemplate now
initializes slightly differently as a result (with both `branding_name`
and `branding_text`).
Platform admin users can still see the organisation breadcrumbs for
trial mode services, but others uses can only see organisation
breadcrumbs for live services.
Organisation team members only have access to the dashboard if they’re
also a member of that service.
They always have access to the usage page, so let’s link there instead.
Organisation team members will be ultimately interested in the detailed
usage of each service, but shouldn't necessarily have access to the
personal data of that services users.
So we should allow these organisation team members to navigate to live
services usage page from the organisation page. They may need to contact
the team so they should also be able to view the team members page.
So they'll then see just usage and team members pages.
If they are actually a team member of the service they're viewing, then
they'll see the full range of options as usual.
This commit implement the above by adding an extra flag to the
`user.has_permissions` decorator which allows certain pages to be marked
as viewable by an organisation user. The default (for all other existing
pages) is that organisation users don’t have permission.
It’s a bit more concise to use these methods, rather than access the
lists directly.
And because it’s easier to read it will make later refactoring less
bothersome.
Added a breadcrumb link to a service's organisation to the
withnav_template. This will only show if a service has an organisation
and the current user is also a member of that org, or the current user
is a platform admin user.
Also removed a couple of unused fixtures from the client_request
fixture.
When someone selects that they are accepting the agreement on behalf of
someone else then they need to provide that person’s details. Otherwise
they shouldn’t care about these extra fields.
This commit uses the progressive disclosure pattern from the GOV.UK
Frontend Toolkit to hide the additional fields unless someone selects
the relevant radio button.
If the user has selected that they are accepting the agreement on behalf
of someone else then we need to make the they provide that person’s
details.
If they’ve selected that they are accepting the agreement themselves
then we have to ignore what they might have put in the ‘on behalf of
boxes’ (for example if they filled them out but then changed their
mind).
At the moment, the process for accepting the data sharing and financial
agreement is:
1. download a pdf
* print it out
* get someone to sign it
* scan it
* email it back to us
* we rename the file and save it in Google Drive
* we then update the organisation to say the MOU is signed
* sometimes we also:
* print it out and get it counter-signed
* scan it again
* email it back to the service
Let's not do that any more.
When the first service for an organisation that doesn't have the
agreement in place is in the process of going live, then they should
be able to accept the agreement online as part of the go live flow. This
commit adds the pages that let someone do that.
Where the checklist shows the agreement as **[not completed]** then
they can follow a link where they can download it (as happens now).
From here, they should then also be able to provide some info to accept
it. The info that we need is:
**Version** – because we version the agreements occasionally, we need to
know which version they are accepting. It may not be the latest one if
they downloaded it a while ago and it took time to be signed off
**Who is accepting the agreement** – this will often be someone in the
finance team, and not necessarily a team member, so we should let the
person either accept as themselves, or on behalf of someone else. If
it's on behalf of someone else we need to the name and email address of
that person so we have that on record. Obvs if it's them accepting it
themselves, we have that already (so we just store their user ID and
not their name or email address).
We then replay the collected info back in a sort of legally
binding kind of way pulling in the organisation name too. The wording
we’re using is inspired by what GOV.UK Pay have. Then there’s a big
green button they can click to accept the agreement, which stores their
user ID and and timestamp.
If it’s something weird like an instance of a Python object let’s ignore
it (else we get invalid HTML like
`id='<notifications_utils.columns.Cell object at 0x1126f4e80>'`).
The scrollable tables code styles some of the cells in the target table
by looking for the `table-field-center-aligned` class.
This class was renamed in 0512f40ad3
This commit updates the scrollable tables code to refer to the new
classname, which means that things should line up properly when drawing
the table.
