Service names can be quite long. Organisation names can be quite long.
Together they can be very long. This isn’t great because:
- sometimes they overflow the width of the container, which looks broken
- even if they’re not that long they can make the UI look quite
cluttered
This commit restricts them to widths that should stop the above from
happening. In the case of the organisation name the width has
specifically been chosen to line up with the ¼ and ¾ column grid
used by the navigation.
Currently we set not-very-useful defaults for organisation type and
crown status when creating an organisation. This commit adds two field
to the form (in addition to the existing name field) to explicitly ask
for:
- organisation type
- crown status
We need these for all organisations before we can make any of their
services live.
This commit also records any new organisation as not having accepted the
data sharing and financial agreement, because if we don’t know about the
organisation already then they definitely won’t have signed it.
Rather than force us to write the decorators in a specific order let’s
just have one decorator call the other. This should make fewer lines of
code, and fewer annoying test failures. It also means that the same way
of raising a `401` (through the `current_app` method) is used
everywhere.
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.
so that platform admins (us) can view pages as regular users do easily.
Simply adds a flag in the session cookie that overrides the actual
platform admin flag on the user model if set. This way it's safe, since
this only downgrades existing functionality, so if someone managed to
alter it they could only get less permissions, not more.
You can change this value from the user profile page if either:
* you're a platform admin
* the flag is set (to any value) on the cookie.
This slightly weird check means that we don't check the underlying
`user._platform_admin` flag anywhere in the code, even when toggling
the suppression.
This should make the ‘All organisations’ page load a lil’ bit quicker.
Still worth caching the domains separately so the response is smaller
when we only care about domains. This is because the code that uses the
domains is part of the sign up flow, so it’s really important that it’s
snappy.
