Includes adding filtering to the user permissions
data.
Classes extending BasePermissionsForm have their
user permissions handled by permissions_field
which stores its data in a list. This replaces the
previous approach of having a BooleanField for
each role.
Because permissions_field.data is taken directly
from POST data, it needs extra guarding against
values not present in whatever roles model the
class is based on (ie. broadcast_permissions).
This removes the edit_folder_permission checks from the code, enabling
the folder permissions for all services.
This also fixes folder-related tests to set up appropriate user
permissions.
This should only be merged right after alphagov/notifications-api#2428,
when all other permission stories are done.
Platform admin users can access all template folders, so the folder
permissions form always displays everything as checked for them,
which makes it look like the form isn't actually working. We could
do the check based on folder data, but the field still wouldn't
have any effect on permissions. So instead, we hide it completely
for platform admin users.
Submitting the form will remove any folder permissions from the DB
for the platform admin user (which can still be created by changing
permissions on the template folder 'Manage' page), but that's only
relevant if a user stops being a platform admin but keeps their
Notify services.
Expands the API of the macro to allow nested
checkboxes to have a summary tracking the current
selection, the fieldset to expand/collapse and
buttons to be added to allow jumping between
states.
Includes making 'Done' button inline on mobile.
Helps differentiate it form the form submit.
Integrates the folder permissions form with the updated API endpoint
to store changes in the user folders.
Since user folder permissions are returned in the full list of template
folders for the service we need to invalidate the cache key for it each
time we update user permissions.
We're reusing the logic for the `move_to` nested radios field for the
user folder permissions nested checkboxes.
The main difference between the two forms (aside from the different
input type) is that "Move" form contains the root "Templates" as an
option, whereas the folder permissions doesn't.
It turns out that, because of the way NestedFieldMixin.children and
select_nested macro are implemented the easiest way to get the desired
folder permissions behaviour is to add the root folder as a choice with
a `None` value and `NONE_OPTION_VALUE = None` set on the field, which
allows the `child_map` to be constructed but doesn't display the root
folder checkbox itself since it gets overwritten in the final `child_map`.
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.
The page where you switch on the feature
---
This content aims to describe:
- the benefit of basic view – ‘make Notify quicker and simpler’
- who it benefits – ‘team members who only need to send messages’
- how it does it – ‘by hiding…’
- what it prevents users from being able to do or see – ‘everything
except…’
- what it allows users to do – ‘send messages’, [see] ‘templates, a list
of sent messages’
I’m still keen to mention sent messages here, as it feels weird not to
mention it at all when it’s 1 of only 2 options in Basic view. I don’t
think it’s as important to mention it on the Edit team member screen.
I’ve specifically used ‘a list of sent messages’ rather than just ‘sent
messages’, to make it seem less like a noun (new feature).
The page where you choose whether someone has basic view
---
Switches the focus from what you can see to what you can’t.
Aims to be consistent with both:
- the description of permissions in admin view
- the language used to describe basic view in settings
‘Caseworker’ was a bad name because it:
- suggested that Notify might be expanding into case management
- may or may not map to someone’s actual role, in a confusing way (this
is why ‘manager’ is also a bad name)
‘Basic view’ is the best name we could come up with because:
- it describes the purpose of feature, not the user
- a ‘view’ changes what you can _see_ as much as it changes what you can
do
Admin remains a good word – in research users self-describe their use
of Notify in using it. This commit makes the name ‘admin view’ to match
‘basic view’.
This also means we can hide the legend for this fieldset because the
choices are self-explanatory.
In research we found that:
- people didn’t initially realise that the permissions expanded when the
‘admin’ option was selected
- not having all the options visible at once makes it hard to know what
permissions you are (and more importantly aren’t) giving to people
This commit makes it so that:
- the options within the ‘admin’ option are always visible
- a bit of Javascript logic makes it so you can pick ‘caseworker’ and
‘manage service’, for example (by deselecting one when you pick the
other)
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.
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.
The visual appearance of radio and checkbox form inputs changed in
GOV.UK Elements here:
https://github.com/alphagov/govuk_elements/pull/296
This was subsequently reimplemented with different markup and no
Javascript here:
https://github.com/alphagov/govuk_elements/pull/406
This has meant making the following changes to our app:
- changing the markup in our radio/checkbox macros to match the example
markup given by GOV.UK Elements
- removing the previous Javascript file because it’s no longer needed to
make the radios appear visual selected
- making the buttons on the scheduled job picker look like links,
because the grey button style looked weird with the new radio buttons
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.
