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.
It’s confusing showing green ticks for cancelled invites. This commit
changes the appearance so that only pending or active users (ie those
that could actually do some damage) get green ticks.
Also fixes missing edit links caused by instances of `User` having
`.state` but instances of `InvitedUser` having `.status`.
Right now these are two separate lists. Which makes it harder to add
improvements that will make large numbers of users easier to manage.
Another thing we did for templates, when they started to get
unmanageable, was add a find-as-you type search. We’ve observed real
users interacting with this to great effect, so I think it makes sense
for users too.
Like for templates, it only shows up when there are more than 7, so that
it’s not clutter for teams who don’t have a lot of members.
We’ve moved from three to four permissions. Four permissions don’t fit
in the exiting horizontal layout.
This commit makes the permissions stack vertically instead.
This approach has some downsides:
- makes the permissions less easy to scan vertically
- makes them take up a lot more space (and at lives services, most of
them have somewhere around 15 team members)
But I think for now it’s better than any horizontal alternative that I
tried.
We’ve seen from research (a long time ago) that the ‘manage service’
permission is too broad, and gives too much control to someone who only
needs the ability to edit templates. In other words, editing content
should be its own, separate permission, rather than being rolled up
into manage service.
Since this is already disaggregated on the API side, making this change
just means changing the mapping on the admin side and adding an extra
checkbox on the invite/edit page. Which is what this commit does.
So for now, an existing user who has the manage service permission gets
both manage service and manage templates (ie no change to what they can
do). Newly invited users will get to choose if they have both, either,
or neither.
This commit makes the existing tests around user permissions less
verbose by using the new `client_request` fixture.
This fixture takes care of:
- setting up a service
- asserting that the response is `200`
It also tests that the page titles, some of which didn’t match with the
`<h1>`s, so this commit also fixes that mismatch.
There’s a lot of repeated code in our Jinja templates for the settings
page.
We already have a `boolean_field` component, but it’s not used anywhere
(it was just lifted from Digital Marketplace).
So this commit changes the `boolean_field` component to be useful for
our on/off use case, and wires it into the settings page.
In pages specific to a service (e.g. dashboard and sub pages) the title
needs to distinguish which service it applies to. This is mainly to give
context to screen reader users who could be managing multiple services.
Implementing this uses template inheritance:
`page_title` includes `per_page_title` includes `service_page_title`
‘GOV.UK Notify’ is inserted into every page title.
Pages that set `service_page_title` get the service name inserted too.
Right now, a user can change their name and masquerade as someone else
and the service manager has no way of telling who is who.
This is also true for platform admins, where they can see the users of
a service but can’t identify which department they are from.
This commit adds a user’s email address next to their name to remedy
this.
The team page was a bit of a mess:
- invited and active tables didn’t line up
- lots of things were wrapping onto two lines
- the empty fields for when a user didn’t have permissions looked broken
This commit splits each row of the table (not actually a table any more)
onto two lines. First line has the user’s info, second has their
permissions and any associated actions.
When a table is showing the contents of a CSV file, it should look
something like a spreadsheet.
The minimally skeuomorphic way to do this is by adding row numbers.
This commit doesn’t
- make the row numbers monospace (it’s barely noticeable and doesn’t
reflect what actual spreadsheets do)
- make the first column heading ‘Row’ (again, doesn’t reflect how actual
spreadsheets work, and takes up more valuable space)
Because ‘Send text messages’ isn’t very helpful if you’re looking to
edit a template.
It also helps front-load the navigation, ie ‘Team’ is the first word,
rather than the more generic ‘Manage’.
A new permission has been added, view_activity, to resolve this issue.
Another pull request in notifications-admin will be required to update all users with a default permission of view_activity.
The yes/no pattern didn’t work too well, because:
- it didn’t read naturally as a question and answer
- often users left them completely unclicked if they didn’t want to set
the permission (rather than clicking no)
This commit changes both the invite and edit user pages to use
checkboxes to set permissions. If also rewords these pages to read more
naturally, and explain what the permissions mean.
This meant changing some of the view logic around invites and
persmissions, and I ended up refactoring a bunch of it because I found
it hard to understand what was going on.
On the send messages and manage team pages we have big green buttons for
adding/inviting a new template or team member.
On the add template page it was at the bottom, and often got missed.
On the manage team page it was at the top, but maybe too prominent because it’s
big and green.
This commit tries putting it in the top right of the page instead (except when
the template page is empty, in which case it’s unchanged).
This commit only deals with acceptance by
users who are already in system.
Changed invite client to return invited user objects
instead of dictionaries.
Added commented out test. fixed up fixtures to return invited user
object for invites
This takes the original prototype version of this page, and, using the same
fake data (ie nothing is wired up):
- adds an invite users page
- adds an edit (and delete) user page
Both these pages allow the user to set another user’s permissions.
This commit adds images for the ticks and crosses, so we have control over their
appearance.
This commit modifies the HTML `<title>` tags for all the pages. It makes two
main changes:
- make the title tag match the `<h1>` of the page, for better or worse
- put the service name after the page title, seperated by an en dash, as per
GOV.UK
