This tag was not showing up in the call to the Zendesk API because the
return value of a generator is not included as a member of that
generator (on things `yield`ed from it are).
At the moment we manually tag tickets as they come in so we can analyse
how many of each type we’re getting.
Further, we manually tag all the request to go live tickets once a month
to analyse how many are complete/incomplete.
All this tagging is useful, but quite time consuming. Notify already
knows this information and – using the Zendesk API – we can tag them
automatically.
I’ve checked with Holly and this is the taxonomy we want to use.
We don't show the sender addresses and letter branding on the settings page
if a service doesn't have letters enabled, so we should also hide the
postage for services that can't send letters.
(Postage can only be seen by Platform Admin users at the moment, but this will
change later).
We’ve learned of a change implemented today by the UK mobile
network operators, to stop allowing text message sender names
of 3 or less characters.
Adding this validation will not affect existing senders, only those
users trying to add to or update their senders.
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.
