At the moment this won’t look like much, but it will let us do an
end-to-end run of adding a broadcast template.
At the moment all you can do with a broadcast template is edit it, so
there’s no ‘Send’ link on the page.
At the moment the page is the same as for text message templates,
except:
- different H1
- no guidance about personalisation, links, etc (until we decide how
these should work)
For now you won’t be able to really create a broadcast template, because
the API doesn’t support it (the API will respond with a 400). But that’s
OK because no real services have the broadcast permission yet.
This required a bit of refactoring of how we check which template types
a service can use, because there were some hard-coded assumptions about
emails and text messages.
This should:
- make the page load faster because it has to render less HTML for each
service
- make the page easier to scan for services that are sending lots of
text messages or letters
We used to scan this page to look for services with high failure rates,
and the design of the page was gear towards this. Now we have alerting
for high failure rates, so the page can focus on volumes instead.
This commit also puts the service name above the statistics, so that
long service names don’t break the layout of the page.
We’re removing it for performance reasons.
This means removing the old pages that edited the letter contact block
when it was stored directly on the service, rather than the current
model where a service can have multiple contact blocks.
This should speed things up by:
- less time waiting for big blobs of JSON to come from Redis or the API
- less time spent deserialising big blobs of JSON
‘Commonly used passwords’ is more specific, and avoids the terminology
‘blacklist’ which the National Cyber Security Centre explain to be
problematic:
> It's fairly common to say whitelisting and blacklisting to describe desirable and undesirable things in cyber security. For instance, when talking about which applications you will allow or deny on your corporate network; or deciding which bad passwords you want your users not to be able to use.
>
> However, there's an issue with the terminology. It only makes sense if you equate white with 'good, permitted, safe' and black with 'bad, dangerous, forbidden'. There are some obvious problems with this. So in the name of helping to stamp out racism in cyber security, we will
> avoid this casually pejorative wording on our website in the future. No, it's not the biggest issue in the world - but to borrow a slogan from elsewhere: every little helps.
– https://www.ncsc.gov.uk/blog-post/terminology-its-not-black-and-white
See c31264d4c for why ‘whitelist’ should be avoided. The use of
whitelist here was not referring to the user-maintained list, but to
mean ‘not a government’ email address. This commit renames these tests
to make that difference clear.
