One of the big things we found in user research was that people were
uncertain what the effect of giving someone basic view was.
So in the spirit of ‘show don’t tell’, this commit adds a way for users
to preview basic view. They can go into the preview and click around as
much as they like, just as if they really had the basic view assigned to
them.
Once they have seen enough they can return to the settings page where
they can decide whether or not to switch basic view on for real.
Since platform admins can use the new settings page, this commit:
- links to that page
- removes the platform-admin-only endpoint that switches basic view on
and off
This commit adds radio buttons to the ‘basic view’ page. This will let
users choose whether basic view is on or off for their service.
As before, this page will only be linked to if a service already has
basic view, so this commit does not launch the new feature.
This commit adds:
- a row to the settings page…
- …which links to a page explaining what basic view is
The new row (and link) will only appear for services who already have
the feature switched on. This is because we are not launching the
feature yet, so it shouldn’t be available to just anyone.
Often we show/hide these rows based on what permissions a service has.
This commits refactors that check into a reusable macro, rather than
having to write the same `if` statements all the time.
We are not consistent about this. We use ‘manage service’ on:
- the page listing all the users
- the request to go live checklist
We use modify service on:
- the page where you edit a team member’s permissions
- the page where you invite a new team member
This commit changes the latter to be consistent with the former.
‘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.
There was a bug where caseworking users skipped the part of the invite
flow where their invite was cleared from the session. This caused
a 500 if they later tried to create another service.
This commit makes sure that both types of user have the invite cleared
from the session after accepting it.
This link is useful for people who are setting up templates and want to
test out how they look/how Notify works.
‘Caseworker’ users shouldn’t need to send themselves messages on a
regular basis, so this link is another thing we can take away.
Counts of sending/failed/delivered are ‘management information’ or
‘reporting’. We don’t think that caseworkers need to see this
information.
The idea of the caseworking view is to remove stuff that caseworkers
don’t need to see.
The other task that caseworkers have to do (much less often than sending
messages) is look at the messages which they’ve sent. The reason for
doing this is usually to find a specific message which someone has
complained about.
This commit adds:
- a page where they can do that
- a navigation item so they can get to that page
We reckon that because this is about finding specific messages, not
reporting that it’s fine to mush all the channels (email, text, letter)
into one table.
No-one can at the moment, but when we bring the links back we should
only bring them back for users who care about reporting and management
information, ie those with the `view_activity` permission.
Caseworkers skip the template page in their message sending journey.
Instead they go straight from picking a template to the first step of
sending. So the ‘Back’ link should send them straight back to the
picking a template page, skipping the individual template page (which
they don’t have permission to view).
The main task that we think ‘caseworker’ users do is send one off
messages.
So this commit:
- makes sure users who don’t have the `view_activity` permission (ie
not ‘admin’ users) can still send messages
- adds navigation so that these users have a place to go from which to
start the process of sending a one off message
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.
This commit splits up the radio buttons macro into a couple of different
macros which can be used independently of each other.
This makes this code easier to reuse when implementing custom radio
controls.
There are three parts to a ‘user’ form:
- the email address
- the permissions
- the auth type setting
This commit breaks them up into abstract classes so that they can be
composed more flexibly in future commits.
Eventually the ability to have the caseworking view for your service
will be self-service. But while we’re still building it only we should
be able to enable it, for our own testing purposes.
So this commit adds platform admin functionality to switch the feature
on and off for our services.
We’ve had a user who’s said:
> Seems configured callbacks cannot be removed once they’re set as the
> fields have a presence check. Is that intentional?
This means it’s not working as they expect. Rather than have to go and
change stuff in the database for them, let’s make it work as they’d
expect.
Only lets you clear the form if you remove both the token and the URL.
Sometimes a user will hit the green button without actually changing
the service name (we saw this in a usability testing session).
Currently this gives an error saying ‘service name already in use’,
which is technically true (it’s in use by the current service) but
practically just annoying.
This commit adds some logic to silently ignore such requests.
Check that the format of the dates entered is in the `YYYY-MM-DD` as
specified and show an error message if it is not. If the date was not in
the specified format, there would be no error message but the content of
the page would change which was misleading.
In API, the endpoint for the new platform admin stats page has been
moved to a platform stats blueprint. This means we now need a platform
stats client.
Added a new platform admin page, at '/plaform-admin-new' which shows
different data. This no longer offers the option to filter by test-key,
only by date, and also gives a more detailed break-down of the
notifications and failures sent with a normal / research key.
The existing platform admin stats page ('/platform-admin') has not been
deleted yet so that both pages can be compared.
* Added a new method to the ComplaintApiClient to get the total
complaints by date range from the API.
* Added a new method to the ServiceAPIClient to get the new platform
admin stats data from the API.
