At the moment the dashboard does two API calls to find out if a service
has:
1. Scheduled jobs
2. Normal jobs
API calls are slow because they are synchronous, go over the network and
touch the database. We can’t cache these API calls because:
- a scheduled job could become a normal job at any time
- the statistics on a normal job are constantly updating
However there are plenty of services which don’t have any jobs, and
probably never will. And finding out if a service has any jobs is
reliably cacheable (because as soon as a service creates its first job
it has some jobs).
So this commit:
- refactors the way we get scheduled/normal jobs into the job_api_client
to make the view a bit slimmer
- makes an additional, Redis-wrapped call to find out if any jobs exist
before trying to get the jobs
This should result in a speedup on the dashboard, and can be used in the
future if there’s anywhere else we want to show or hide something
depending on whether a service has created any jobs (I have some ideas).
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.
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.
Commit 58cc1604a7 sanitises any non-ascii
characters in the headers. CSV filenames get used as a header value, so
this fixed a bug that occurred when non-ascii characters were used.
The CSV filename also gets used as part of the metadata when uploading
the file to S3. Since the S3 metadata can only contain ASII characters,
we also need to sanitise the filename before uploading it to S3.
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.
Things we’ve noticed from looking at real data that we could handle in a
smarter way:
- removing numbers (there might be a tom.smith2@dept.gov.uk if tom.smith
is already taken)
- removing middle initials (again, these tend to be used for
disambiguation and aren’t included when we ask people for their names)
- ignoring email addresses which only have someone’s initial, not their
first name (because we can’t make a decent guess in this case)
