Also add more tests for showing or not the cancel those letters link
Also check if all notifications already in database
Upgrade delete button text logic to handle more cases
Also corrections following review
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.
