Added a new row to the settings table, 'Post class', which shows the
default letter class of a service and is only visible to Platform Admin.
Also added a new page to enable Platform Admin users to change the
default letter class for a service - this only has two options at the
moment, 1st class only and 2nd class only.
A platform admin form accepts a list of references (one per line)
received from DVLA and sends them to the API to update notification
statuses.
References we get from DVLA start with `NOTIFY00\d`, which isn't
part of the reference we store in the database, so we remove them
before sending the data to the API.
The new `returned-letter` status should be treated as `delivered`
for now until we decide a way to display returned letters to users.
If a message has been sent with a test key it’s a bit confusing to just
say ‘Delivered’ on the page, because it hasn’t gone to anyone’s phone.
So this commit adds a bit of hint text to disambiguate what ‘Delivered’
actually means in this context.
Anyone choosing ‘NHS’ for their organisation type gets should get the
NHS branding. We don’t want to hard-code an ID for NHS branding anywhere
because it won’t be consistent between environments.
So instead we can say that anyone who chooses ‘NHS’ as their
organisation type should get whatever branding has `nhs.uk` as its
domain.
This allows us to easily manage the branding the same way we do other
brands, but gives us the efficiency of having it auto applied.
So that:
- we can see when a brand should be getting used as a default but isn’t
- we’re careful updating brands which will get auto-applied to new
services
When a user creates a service we can take a pretty good guess at what
organisation they’re from.
For many organisations, especially local councils, GOV.UK branding is
not appropriate for their service. But right now every service:
- gets created with GOV.UK branding
- has to ask us to change it, even if they’ve already done so for other
services they run
This commit starts using the `domain` field on the email branding table
to lookup what email branding to assign to a service automatically,
where we’re sure there’s a sensible default.
There’s something that feels a bit off about not being able to see the
name of the currently-selected branding when you land on the page.
Putting it at the top also means that you can easily switch back to it
if you change your mind.
Since GDPR came into effect it’s less clear about whether we can
contact teams for user research purposes.
If we make people opt-in (or not) we know we’re safe to contact them (or
not).
Since we mostly care about how services are using Notify for real (ie
live services) or services that are considering adopting it (ie those
who have contacted us with a question) it feels like the go-live process
is the most appropriate place to collect this consent.
Now that we’re a more mature platform we don’t care so much about the
load that one service might put on our platform.
We do care about intended volumes for two reasons:
- modelling the benefits that services get from using Notify
- managing stocks of envelopes (while our letter volumes are small
enough that they could be skewed by one new service)
Changing to the ‘how many per year’ question also has the benefit of
mapping directly to the data we store in the ‘beta partners’
spreadsheet.
Currently we keep track of live services in the ‘beta partners’
spreadsheet:
https://docs.google.com/spreadsheets/d/1JYhE5sJaOJUVMPPDenO2eKqElC75Rygxb1_2mpRKy98/edit#gid=503930061
Every time a service goes live we need to enter some data into the
spreadsheet about that service. Most of that data is copied from the
request to go live ticket.
This commit adds a line to the ticket with all the data needed by the
spreadsheet. It’s in the same order as in the spreadsheet, and it’s
tab-delimted so it should paste right on in there.
Setting the branding_style to 'None' causes the
API to remove the email_branding field from a
service model. The branding request page
controller was depending on that value being
to present get the brand type.
The email preview page (used in an iframe on
various pages) wasn't able to recognise a
branding_style of 'None', causing a blank page to
render.
We often check that a service has an appropriate text message sender as
a condition of them going live. We don’t mention this anywhere.
The services for whom GOVUK is definitely not an appropriate sender are
those in local government. As we have more of these teams starting to
use Notify, we should streamline the process by making this check
automated.
This commit adds that check, for teams who:
- have text message templates
- have self-declared as NHS or local government
Selecting a branding just takes you to a new page, it doesn’t change
any state.
Links are generally the way you go from one page to another on the web.
One of the most frequent tasks done on this page is adding a new
branding.
Current to do this you have to:
- scroll to the bottom
- scan for the ‘Create a new email branding’ option that visually looks
just like all the other brandings
- submit a form
This commit makes change it to one clearly differentiated button at the
top of the page. This is consistent for how we let users add templates
and team members.
At the moment there’s nothing in Notify that says the logo on letter
templates can be changed from ‘HM Government’. While some people guess
that it’s possible, or are motivated enough to enquire, others might be
assuming that the branding can’t be changed (and thus deciding Notify
letters aren’t for them).
In the future we should make this process slicker (eg with a file
upload) but the easiest, quickest improvement to make for now is:
- let people know that the branding can be changed
- direct them to support if they do want to change it
Minor changes to the number formatting for the `/platform-admin` page to
- Show the complaint percentage to 2 decimal places. (The number of
complaints is often below 0.0% so 1 decimal place isn't useful)
- Format the numbers in the status boxes to use a comma as a thousands
separator.
Admin, API and utils were all defining a value for SMS_CHAR_COUNT_LIMIT.
This value has been updated in notifications-utils to allow text
messages to be 4 fragments long and notifications-admin now gets the value of
SMS_CHAR_COUNT_LIMIT from notifications-utils instead of defining it in
config.
