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.
When there is a uniqueness constraint on a DB column you can still have
multiple null values.
You can’t have multiple empty string values.
We are trying to save the domain as empty string when creating or
updating a new branding. This means that it’s currently not possible to
create or update a branding with no domain, because the uniqueness
constraint is violated.
For some reason we are getting pending back as a status from one of
our text message providers.
Because this is unrecognised by the admin app it shows up in the list of
messages as the raw status, styled like an error.
This commit maps it to sending instead, because the user doesn’t need to
know or care about the difference.
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.
Because ‘2 months ago’ is more human-sounding than ‘70 days ago’.
Using this pattern (borrowed from the API integration page) will also
use Javascript to keep the time updated, so ‘just now’ will turn into
‘1 minute ago’ without having to reload the page.
This is useful if you have lots of people sending messages and want to
report on who’s doing what.
Needs the API updating to return `created_by_name` in its response.
At the moment we transform what the user gives us, so if someone enters
`digital.cabinet-office.gov.uk` it will automagically be saved as
`cabinet-office.gov.uk`. This happens without the user knowing, and
might have unintended consequences.
So let’s tell them what the problem is, and let them decide what to do
about it (which might be accepting the canonical domain, or adding a
new organisation to domains.yml first).
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.
It’s useful to be able to see what the email or text message looks like,
especially if you’ve sent it with a test API key (so it isn’t in your
inbox or on your phone). We already have the page for this, so we just
need to link to it.
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.
When saving an email branding it’s possible we might not enter the
canonical domain for an organisation into the domain field. Because
we’re going to use the canonical domain to look up the brandings this
will cause a mismatch.
Rather than validate this and show an error, let’s just save the correct
thing instead. From the user’s perspective this means everything will
just work (ie a user with a given email address will automatically get
the right branding for their organisation).
We should make sure we’re not putting typos in the branding list. We can
validate what gets entered here against our known list of public-sector
domains.
Because we alias domains (eg `foo.gsi.gov.uk` to `foo.gov.uk`, or where
a local council has multiple domains) it could be hard to look up a
brand (which has one domain field).
Therefore we need a way of getting the canonical domain from a user’s
email address, which we can later use to look up their branding.
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.
