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.
Otherwise you have a visible copy of the text underlapping the text in the textbox. Which, when they don’t quite align makes the text look bold. Seems to be more noticeable on some browsers/operating systems than others, but a bug all the same.
If there aren’t a range of options (normally presented as radio buttons)
to show the user on the email branding request page then we just show
the textbox. But we were still doing form validation on the radio
buttons, even though the user couldn’t see them to click them. This
stopped the user from being able to submit the form.
This commit fixes the problem by, in this specific case, pre-ticking the
‘Something else’ radio button.
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.
Updating an organisation’s branding might now also update the branding
of services associated to that organisation. This is similar to how
updating an organisation’s type can update the organisation type for its
services.
In the latter case we already make sure to clear the cached version of
these services which is held in Redis.
This commit does the same clearing of the caches when updating an
organisation’s branding (and does a bit of refactoring to do so without
duplication of code.)
When testing with the JAWS screenreader, we found
a bug around getting it to announce the name of a
fieldset when we ask the user to select from it.
Bug on pivotal:
https://www.pivotaltracker.com/story/show/165565088
The flows for adding a new template and moving a
template/folder both need the user to select an
option from a radio group. When we add the radio
group to the UI, we need to move focus to it so
the user is in the right place to choose an
option.
The expectation of the original code was that
focusing the field set's legend would work like
focusing the heading of a section of content and
announce the label of it. This didn't happen with
JAWS. This tries to achieve the same by focusing
the whole fieldset instead.
When doing this we also hide the focus style, to
follow the convention for this across www.gov.uk.
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.
