If an invite is cancelled then the user no longer has permission to do
anything, so we shouldn’t show the green tick. We already do this for
other permissions; this makes the ‘basic view’ row consistent.
It looks too prominent as a paragraph on the page. This commit moves
the info about how long we keep data for into the ‘empty’ message we
show when there are no results (ie the message people will see if they
search for something that was sent more than 7 days ago).
Can’t think of a good reason why someone who is only sending messages
would need a download of all the messages their entire team has sent.
Most of the ‘caseworking’ teams have been getting on fine without this
link; it’s only recently we brought it back.
We had kept the original platform-admin page at `/platform-admin` and
created a new page, `/platform-admin-new` for the new platform admin
page. Now that the numbers on both pages look ok we no longer need both
pages, so can replace the original page.
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.
‘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.
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.
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.
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.
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.
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.
We’ve supported this for a while but don’t tell anyone how to do it.
This commit also alters the spacing of things so the description groups
better with the example.
This works locally for a long running request and a large number of messages. However I suspect that nginx may be timing out the request. I'd like to try this on staging.
The contact link on the settings page should be truncated instead of the
text being wrapped and overflowing on to multiple lines. This adds in an
option to the text_field macro to truncate long text fields. This
setting has been used to truncate the API callback URLs too on the
services/<service_id>/api/callbacks page.
When a platform admin user clicks on the button to add the
'upload_document' permission to a service, they should be taken to the
page to add a contact_link if the service does not already have one.
The contact link for the service now gets displayed on the service
settings page if the service has the 'upload_document' permission. There
are no changes to the appearance of the service settings page if a
service does not have the 'upload_document' permission.
Added a page which lets users with the 'manage_service' permission change the
contact link for their service. There are no links to this page yet
since only services using document download will need to set a contact
link.
