We’re interested to know which services are looking at the basic view
preview (even if they’re not turning it on).
This commit logs their service IDs as events into Google Analytics.
There are some teams who send jobs on a daily/weekly basis. They have
team members who only use Notify for this purpose. So they would
probably benefit from basic view, because they don’t need to see the
dashboard.
This commit:
- adds a new item (uploaded files) to the basic view navigation for
teams that have sent at least one job
- makes the job pages visible to basic view users
I think we should do this now, rather than as a later enhancement to
basic view. We only have one chance to announce the feature, so teams
who do send jobs may otherwise discount it as not useful for them and
the opportunity to have them use it is lost.
This is better than just keying into the JSON because it means you get
an exception straight away when looking up a key that doesn’t exist
(which via mocking you could ordinarily miss).
Having the service floating about as JSON is a bit flakey. Could easily
introduce a mistake where you mistype the name of a key and silently
get `None`.
Also means doing awkward things like `if 'permission' in
current_service['permissions']`, whereas for users we can do the
much cleaner `user.has_permission()`.
So this commit:
- introduces a model
- adds a `.has_permission` method similar to the one we have for users
The list of services this page was looking at only included those not
belonging to an organisation.
On production this excludes services we’ve added to organisations to
make the management of those services easier (eg ‘GDS’ and ‘DVLA’).
Sometimes when setting up a service you might have a few very similar
templates, in which only a small amount of content. Or you might even
have a few of services, which are used by different teams but have
similar templates.
Copy and pasting, especially from one service to another, is a pain.
This commit makes it easier by allowing users to copy an existing
template when choosing to add a new one, instead of starting from
scratch.
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
Two tests retained the old syntax because of mocker conflict:
when logging in as a user through client_request, it sets up a
side_effect on user_api_client.get_user to the user you log in
as. If you later want to set return_value for get_user to
something else, problems start :d.
> Suggest making the H1 visible here for consistency, but also to make
> it clear to users what they’re looking at.
> This screen is similar to – but not exactly the same as – the
> individual text, email and letter dashboard screens from Admin view,
> so the H1 could help to distinguish it from them for users who may
> have interacted with both.
From Karl:
> Templates – this should be consistent with Admin view. Users may
> switch from Basic to Admin view (or vice versa), they will also
> interact with users who have a different view or permissions to them.
> Neither should have to learn new interfaces and language if possible.
> ‘Send a message’ was a nice, active label – but Notify options aren’t
> usually actions. If we’re going to change this we should be consistent
> across both Admin and Basic views.
> For the same reason, I have rejected ‘see’, ‘search’ and ‘view sent
> messages’. It will be interesting to see in user testing whether users
> read ‘sent messages’ as ‘send messages’.
- name
- email
- phone number
- services
- last login
- failed login attempts if any
The view can be accessed from results of find_users_by_email
logged_in_at added to User serialization on admin frontend as
a part of this work
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.
