We hid letters originally because it wasn’t a mature feature. We rolled
it out by letting teams choose to use it (#1803)
and then automatically giving it to new teams (notifications-api/#1600).
This commit doesn’t change who has access to letters, but it does make
it more discoverable by revealing it in the UI. This is the same thing we do for emails/texts, where even if you switch them off they still show up on the dashboard and usage
page.
The mixture of three column/two column layouts on this page has always
looked a bit disjointed. And since the left column will only even
contain the names of months, which are short, it doesn’t need a full
half of the page width.
Even if your service doesn’t send letters now, it might have done
previously.
The original reason for hiding letters was because it wasn’t a mature
feature. But now that it is, we should make it discoverable even for
existing teams. So that means not conditionally hiding it.
This is the same thing we do for emails/texts, where even if you switch
them off they still show up on the dashboard and usage page.
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.
Events should be sorted reverse-chronologically, no matter what order
they come back from the API in, or which field in the API response
they’ve been extracted from.
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.
Directly referencing the `ModelList` instances will let us more easily
make choices at the view layer about which kinds of events to show, and
is one less layer of indirection to jump through.
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.
The overlay was showing for any invalid pdf - we only want to show the
overlay for invalid pdf files where there is content outside the
printable area.
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 hardcode this as second class for the moment but eventually
will let the user pick.
Currently the API appears to do no validation, e.g. a json
schema, that rejects API calls with the extra key for postage.
Next steps will be to put a PR into the API that will expect a
postage value in the request and save it with the rest of the
notification. Then when that is done we can add the user interface
to the admin app to let the user pick the postage.
