None of our model or view layer code should need to know about accepted
invites. We don’t use them anywhere because once an invite is accepted
that person is now a user.
Putting this logic in the client means that:
- none of the code calling the client needs to care about accepted
invites
- it’s easier to (if we want) update the API code to not return accepted
invites
This commit is the first step to disentangling the models from the API
clients. With the models in the same folder as the API clients it makes
it hard to import the API clients within the model without getting a
circular import.
After this commit the user API clients still has this problem, but at
least the service API client doesn’t.
Since we have added a new, 5th permission the existing permissions
should be relabelled so that the five make sense as a coherent set.
We especially want to make sure that:
- the labels work against the checkboxes and against the tick/crosses on
the manage users page (a long time ago this page was layed out
differently so didn’t have space for full labels)
- there is no confusion between usage and reports
This commit also:
- re-adds a line about what all users can see (‘sent messages’) but
continues to omit the additional bullet points about templates and
team members (because we think this is clear enough from reading the
permissions)
- refactors the `Form` subclass so that the content and order of the
permissions only have to be defined once
- brings back the ‘permissions’ legend on the `fieldset`
Our research and prototyping around ‘basic view’ found that:
- a lot of users who send messages rarely or never look at the dashboard
(yet it’s the first page they see when they sign in)
- team managers like the idea of taking away things that users don’t
need in order to make the interface simpler
We’ve disentangled the simpler way of sending messages from being part
of ‘basic view’. This means we can give managers the option of taking
away the dashboard as an independent choice, not something that’s
wrapped up in a separate ‘view’.
I think that this checkbox is a more straightforward proposition than
‘basic view’ ever was (despite all the work we did to explain it and
develop the nested checkbox pattern). In research users would often
explain the feature back to us as being about hiding the dashboard – we
should try to make Notify operate in terms of concepts that come
naturally to people wherever possible.
This commit changes the form that the user sees when inviting or editing
another user, if the service has the ‘caseworking’ permission set.
This will allow creating a new type of user, one who only has the
`send_messages` permission, without the `view_activity` permission.
We are doing this because we think there are a number of services with a
lot of users who don’t need to see the dashboard, or the other team
members, and that we can make a simpler interface for these users.
we were seeing isort produce different outputs locally and in docker -
this was due to it having different opinions about whether the tests
module (ie all our unit tests) is a first party (local) or third party
(pip installed) import. It's a first party import, so by defining this
in the setup.cfg isort settings, we can force it to be consistent
between environments.
Note: I don't know why it was different in the first place though
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.
Done using isort[1], with the following command:
```
isort -rc ./app ./tests
```
Adds linting to the `run_tests.sh` script to stop badly-sorted imports
getting re-introduced.
Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because
I think it gives the cleanest diffs, eg:
```
from third_party import (
lib1,
lib2,
lib3,
lib4,
)
```
1. https://pypi.python.org/pypi/isort
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.
Some teams have a lot of users now (I think the record is 172). So we
should make it easier for teams to manage large numbers of users.
This is the same change we made for templates (from most recent to
alphabetical) when the number of templates was getting unmanageable.
Sorted on email address because invited users don’t have a name (and
not sorted on both, because a lot of departments have a
`lastname.firstname` scheme for email addresses, but people generally
enter their names as `Firstname Lastname`).
If we’re going to ‘disable’ radio buttons then we should always tell
users why the radio button is disabled.
This is what we found with the API key choices anyway.
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 sure that the right permission choices are shown in
these pages:
- manage team page
- invite a user page
- edit permissions page
This is in order to make changing these pages easier (see subsequent
commits).
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.
We have a bunch of different styles of handling when function
definitions span multiple lines, which they almost always do with tests.
Here’s why an argument per line, single indent is best:
- cleaner diffs when you change the name of a method (one line change
instead of multiple lines)
- works better on narrow screens, eg Github’s diff view, or with two
terminals side by side on a laptop screen
- works with any editor’s indenting shortcuts, no need for an IDE
Also, trailing comma in the list of arguments is good because adding a
new argument to a method becomes a one line, not two line diff.
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.
We were using a bunch of different styles for form error messages,
including:
- having the name of the field in the error, or not
- can not/cannot/can’t (GDS content styleguide recommends using
contractions)
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’.
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.
