At the moment they can only see it if there are existing jobs. This
commit lets them also see it if their service can upload letters,
because caseworkers might be the ones uploading some letters.
This commit introduces a slightly hacky way of putting usernames against
events, given that the API only returns user IDs.
It does so without:
- making changes to the API
- making a pages that could potentially fire off dozens of API calls (ie
one per user)
This comes with the limitation that it can only get names for those team
members who are still in the team. Otherwise it will say ‘Unknown’.
In the future the API should probably return the name and email address
for the user who initiated the event, and whether that user was acting
in a platform admin capacity.
If you never create any API keys we shouldn’t give you the option to see
API-related events – it will only confuse things.
And since there’s (currently) only one type of event left once you take
API key events out of the picture it doesn’t make sense to show the
filters at all.
At the moment we have two types of event, ‘service’ events and ‘API key’
events. They are munged together which is useful initially, but could
get noisy.
This commit adds filters (copied from the choose template page) that let
users narrow down the list to one of the two types of event. This might
help users get a clearer picture of what’s going on.
Scanning the page is difficult at the moment because it’s hard to tell
how far apart in time events are, and thereby determine which events
might be related.
Grouping the events by day quickly lets users narrow their focus to
a meaningful subset of the events.
We store our audit history in two ways:
1. A list of versions of a service
2. A list of events to do with API keys
In the future there could be auditing data which we want to display that
is stored in other formats (for example the event table).
This commit adds some objects which wrap around the different types of
auditing data, and expose a consistent interface to them. This
architecture will let us:
- write clean code in the presentation layer to display these events on
a page
- add more types of events in the future by subclassing the `Event` data
type, without having to rewrite anything in the presentation layer
We weren't checking if a service was in trial mode when they try to send
an uploaded file. If a service is in trial mode, we now show a banner at
the top of the preview page and no send button.
We now use the pattern of showing a box at the top of the page with the
error. The error message has a heading and can have additional details.
Error messages and the invalid pages get stored in the S3 metadata.
We had been storing whether or not a file was valid in the S3 metadata,
but using the query string of the URL to store the original filename
and the page count. This meant that if you tried to view the preview
letter page without the query string you would see a `500`. It was
possible for this to happen if you were signed out of Notify while on
the preview page - you would be redirected back to the preview page but
without the query string, causing an error.
Add 'Printed' status for letters and update postage information
Discussed with @quis. This change is the first step towards a wider review of the letter statuses.
Removing the word ‘duplicate’ because:
- it suggests that the whole column is the same, which it might not be
- it suggests that having duplicate column names is a problem, which is
only true in the case of recipient columns
Reverts back to saying the column names ‘need to’ match, because we feel
it’s more instructive.
For scheduled files we say ‘sending today at 5:00pm’ or ‘sending
tomorrow at 11:00am’. But once we’ve started processing these files we
say ‘Sent 27 September at 5:00pm’. This makes it sound like 27 September
is not today.
This commit makes the dates shown on the dashboard consistent, by saying
‘today’ and ‘yesterday’ instead of absolute dates.
