lets us keep cabinet office financials safe in the credentials repo
the dict in the creds repo will either be an empty dict or a full dict,
so the env var on paas will always contain some parseable json. But
locally it might not, so if it's not set at all then default to the
string `null` so the json parsing doesn't throw a wobbly.
Previously we relied on the API defaulting this field to an empty
array [1], but that conflicts with using it to decide whether a
broadcast is custom or created in this app.
[1]: 3779146cc5/app/models.py (L2342)
Custom broadcasts created directly via the API app won't have area
IDs since [1], where we started to distinguish between "names" (all
broadcasts have these) and IDs (for broadcasts created in this app).
We forgot to propagate the distinction into the code here.
This code fixes the bug for all broadcasts created after [1]. Any
custom broadcasts created before [1] will have their "ids" field set
instead of "names" so we won't show anything for them. This seems
reasonable as we don't support custom broadcasts yet.
[1]: 023a06d5fb
The CSS that cancelled outline on focus events not
fired by the :focus-visible heuristic is being
overridden by the higher precedence of the outline
style for :focus, due to its use of !important.
This adds !important to the cancelling CSS. This
brings that block up to the same level as that for
:focus, meaning the :focus-visible styles will win
because they sit lower in the stylesheet.
Based on these comments on the associated pull
request:
- add area/areas condition to the array used to
build the label prefix
e2af2f63a4 (r55831534)
- use a for loop instead of while when looping
through nodes
e2af2f63a4 (r55831693)
There is a slight variance in how the line between
the map buttons is rendered when in forced-colors
mode and when not. This is not helped by it
alternately being rendered as either:
- a gap between buttons, showing the container
colour
- a border-bottom on the first button
This attempts to flatten these styles so it is
only styled as a gap between the buttons so
changes to how its colour renders in different
modes can just be dealt with on the container.
The aggregate names don't need to be sorted, but it helps to do
this for the tests, since the implementation of sets may not be
stable between machines and lead to sporadic test failures.
I did also toy with sorting granular area names so they have a
similar ordering, but this would take them out-of-order with IDs
and really the important thing is that the ordering is stable.
I did consider whether to store this explicitly in the SQLite DB,
but this is less effort for now and we can always switch to that
more robust approach in future if we need to.
This applies some heuristics to try and keep the overall list of
areas short when many are selected in the same wider area.
Currently we only have relationship information between upper and
lower tier local authorities, so we can't / won't aggregate up to
Greater London (it's own special thing) or whole countries.
@benthorner pointed out a few things about these
styles that could do with changes:
- the outline-offset will only appear when the
outline does, which is in forced-color mode when
the browser assigns a colour to it, so it
doesn't need to be assigned in a media query
targeting forced-color mode
- the `&:focus:not(:focus-visible)` selector
stops the focus styles showing in scenarios
where:
1. the browser supports :focus-visible
2. focus comes from something other than tabbing
to the map
...so we don't need to target :focus-visible
specifically.
This applies changes to these styles to remove
those not needed and move some to a better place.
Related to this comment on the associated pull
request:
https://github.com/alphagov/notifications-admin/pull/3996#discussion_r699246969
Depends on: https://github.com/alphagov/notifications-api/pull/3314
Previously:
- We introduced a new "areas_2" API field that's can
populate the "areas" column in the same way.
- We updated the Admin app to use the new field, so that
the old "areas" and "simple_polygons" API fields are unused.
- We repurposed the unused "areas" API field to use
the new "areas_2" format.
This PR:
- We can switch the Admin app back to the "areas" field,
but in the new format.
Future PRs:
- Remove support for the unused "areas_2" field (migration complete)
The map is already in the tabbing order, so can be
moved to by tabbing and by programs like screen
readers or speech recognition, but it doesn't have
an accessible name so when assistive tech' that
requires this for identification gets the contents
read out instead, which is confusing.
This adds an accessible name, via aria-label, made
out of the areas the alert targets.
This also adds some help text, explaining how to
use the map via aria-describedby. This is a pretty
common pattern and is used in native UI like
selectboxes where a range of commands are
available to control the UI 'widget'. Using
aria-describedby means the help text is not used
every time the widget is focused but is available
if the user gets stuck. For example, Voiceover
announces it if the widget is focused but
not interacted with for a period of time, or when
a shortcut key is pressed.
Finally, I also added a role of 'region' because
when I tested with the NVDA screen reader, the
accessible name wasn't announced but this fixed
that. I think it's because the div isn't being
recognised as having a role without it being set
explicitly and is therefore ignored.
The content of the map buttons jumped on Chrome
and Safari when focused.
It turns out this was because I was testing in
Firefox which Leaflet had identified as having
touch capability (and so added the .leaflet-touch
class). Leaflet makes the buttons 30px rather than
26px for touch-capable devices/browsers so the
jumping was down to the line-height being set for
the wrong container height.
This adds styles to give a different line-height
when touch is available, to match the Leaflet
styles.
Leaflet does this anyway when they're focused
(through JS) but we found holding shift when on a
focused button, which you do when tabbing
backwards, turns this off for some reason so you
see the outline the browser applies by default.
This turns all outlines off to stop that
happening.
Worth nothing that focus is indicated by:
- a change of background colour instead when
tabbing
- a border in forced-color mode
...so the outline is not needed.
Users on devices/browsers that support touch have
the rounded corners styles applied by this
selector:
.leaflet-touch .leaflet-bar a:first-child,
.leaflet-touch .leaflet-bar a:last-child
It has a higher precedence than the existing
selector we use to override it so our overrides
are ignored:
.leaflet-bar a:first-child,
.leaflet-bar a:last-child
This changes the selector for our block of styles
to include one matching the existing styles above
so devices/browsers also get our styles.
Note 1: this actually means some styles were no
longer needed so this also removes them.
Note 2: oddly, this was spotted in Firefox when
displaying high contrast mode on desktop. So not a
touch device but leaflet's JS is marking it as
such.
This will be run with a CSV of all broadcast messages. Since very
few users are creating or updating broadcasts, it's highly unlikely
we'll encounter a race condition during the update.
