Upcoming changes to API will mean that by default its
`get_notifications_for_service` DAO function will return one-off
notifications. In most cases this is what we want, but the message log
page should not show one-off notifications. By passing in the `include_one_off=False`
option to API we can ensure that this page will stay the same when API
changes.
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
This included:
- creating a new form SearchUsersByEmailForm with validation
on its search field
- introducing 400 status to the view if the form does not validate
- fixing the POST request data structure in the tests (it was
incorrect before and uncaught due to lack of validation and mocking
the response from the API.
