we branch on any_ to either say "require ALL these permissions" or
"require ANY of these permissions". But we only ever call the decorator
with one permission, or with any_=True, so it's unnecessary
rather than allow admins to do everything specifically, we should
only block them from things we conciously don't want them to do.
This is "Don't let platform admins send letters from services they're
not in". Everything else the platform admins can do.
This is step one, adding a restrict_admin_usage flag, and setting that
for those restricted endpoints around creating api keys, uploading CSVs
and sending one-off messages.
Also, this commit separates the two use cases for permissions:
* user.has_permission for access control
* user.has_permission_for_service for user info - this is used for
showing checkboxes on the manage-users page for example
With this, we can remove the admin_override flag from the permission
decorator.
when added to a service, all users are given the view_activity
permission. So, if that's included in the list, we don't need `any_`,
and we don't need any of the other permissions.
platform_admin is a separate concept to permissions, so by removing the
checks for it from the current_user.has_permissions function, we can
simplify things greatly. We already record on the user whether they're
a platform admin anyway.
If someone has duplicate recipient columns in their file we don’t know
which one to use. This commit adds an error message which should help
them fix the duplication.
This commit doesn’t go to the extra effort to actually show the
correct values for duplication in the preview. Don’t think it’s worth
the effort/complexity for how infrequently we’ve seen this error.
Depends on:
- [ ] https://github.com/alphagov/notifications-utils/pull/376
We require that a user has a real reply-to email address before going
live. We can partially automate this by at least telling users who
haven’t done this.
This only applies for users that have email templates; we shouldn’t
bother users who aren’t going to send emails about this.
We need users to have created some templates before they go live, so we
can see what kind of messages they intend to send.
We can do this automatically based on the work done in
https://github.com/alphagov/notifications-admin/pull/1892
One of the things that we want to check before a service goes live is
that they have at least two team members with the manage service
permission. Anyone who can make a request to go live has this
permission, so that means one additional user is needed. This is what we
can automatically communicate to the user.
Under the hood this makes use of the logic added in
https://github.com/alphagov/notifications-admin/pull/1891
Users who have the ‘manage API keys’ permission can see the settings
page. But they don’t have permission to request to go live.
At the moment they can still see the link, though clicking it gives them
a 403 error. This commit changes it so that they can’t see the link, and
tells them who they should speak to about going live (their manager).
We have tickets from people asking how long the process takes. I suspect
that this is because they’re not getting to the bottom of the form
before they’re ready to go live.
A lot of users aren’t reading or paying attention to the checklist on
the request to go live page. We think that we can get more people to
read it by putting it on its own page, where users won’t jump straight
to filling in the form.
This will, later on, let us make this page smarter by automatically
detecting if they’ve done the necessary things.
