When the list of areas is restricted to half the width of the page it
starts to look pretty higgledy-piggledy when you have lots of areas or
areas with very long names.
To do this I’ve ripped out the table markup in favour of headings,
paragraphs and lists. Probably pros and cons for each, but it was really
hard to do the layout with the content in a table.
For emails and text messages we sort by the time the user (or API) sent
them.
This makes sense for broadcasts too, since most users will receive the
alert within seconds of it being broadcast.
For alerts that haven’t started yet we can sort by `updated_at`, which
is when the user preparing the broadcast submitted it for approval.
Now that pending alerts aren’t in their own section there’s nothing to
label them as pending. So this commit replaces the extra metadata we
show for a pending alert (the name of the person who created it, which
was only ever a reckon) with an explicit label that says it’s waiting
for approval.
Splitting the dashboard into multiple sections was confusing, and people
sometimes mistook the headings as labels, especially when a section was
empty. It just wasn’t clear what the hierarchy of the page was.
This commit combines the current and pending broadcasts into one list
on the dashboard. Previous broadcasts have already moved to their own
page.
If you refresh the page on a current broadcast while someone has
cancelled it you’ll see the wrong navigation item selected. This commit
adds redirects to take you to the correct endpoint in these edge cases.
Once a broadcast has been submitted for approval it either lives on the
‘Current alerts’ or ‘Previous alerts’ page, depending on where it is
in its lifecycle.
Therefore when clicking into a broadcast from one of those pages the
same navigation item should remain selected.
Because we select the navigation items based on the request endpoint,
this means we need an endpoint for each navigation page, even if the
content of the pages will be the same in both cases.
This commit adds the two new end points, removes the old, single
endpoint and updates links to point to the new endpoint.
This bit of code is just a safety check to make sure we don’t
inadvertently updating something we shouldn’t (see
0cfe10639a for context).
`rate_limit` is something we allow the admin app to update now (as of
939029a9be).
The following issues were raised with the table
that replays CSV data to users:
1. the table could not be located by low vision
users using the reflow technique
2. the content should be presented in a single
column when the reflow technique is used
Number 2. came from the Web Content Accessibility
guidelines (WCAG) success criteria 1.4.10 Reflow.
I wasn't able to reproduce number 1. so asked the
Digital Accessibility Centre (DAC), who tested it
originally, for help. Tom Shaw from DAC kindly
retested it and found the problem was gone so I am
considering it fixed.
I am treating number 2. as a misinterpretation of
the success criteria as it lists data tables as an
exception to the rule:
"Except for parts of the content which require
two-dimensional layout for usage or meaning.
...Examples of content which requires
two-dimensional layout are images, maps, diagrams,
video, games, presentations, data tables, and
interfaces where it is necessary to keep toolbars
in view while manipulating content."
The full page is here:
https://www.w3.org/WAI/WCAG21/Understanding/reflow.html
The accessibility statement was last updated on 9
October 2020 but without the 'last reviewed' date
being updated.
The changes were contained in this pull request
which was merged the same day and reached
production at 2.13pm.
https://github.com/alphagov/notifications-admin/pull/3677
We were trying to delete the old 'template-{template-id}' keys but
should have been deleting the new keys which have the service id as part
of the key name. This was causing the cache to not be correctly purged
when we did things like update sender names or set defaults. This should
fix it.
