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.
The most important part of the broadcast is what content was sent where
(and when).
This commit reduces the priority of the ‘meta’ information, like who
prepared and approved the broadcast. I also think that the ‘end’ time is
a lot less important than the start time, since most people will receive
the alert at or near to the start time.
This then matches the order in which the message is drafted, first the
content, then the areas. It also matches the order we’re going to have
on the new dashboard.
