- add get/post view
- create a pdf upload form
- add a template where user can upload the file
- check boundaries of the letter by calling template-preview
- display banner messages with boundaries validation result
- display pages of the document, with visible boundaries overlay
if the document did not pass validation, and without overlay
if they do pass validation
We’ve had a support ticket saying:
> Hi, where a letter goes over to two sides, is there a way in the
> 'Preview' screen (or anywhere else) that I can see page two? I can
> see page one OK, but can't work out how to see what's generated on the
> second page.
Whether you’re about to send 1000s of letters – or just want to preview
how one will look – it’s probably useful to be able to see more than
just the first page.
Pytest is deprecating the direct calling of fixtures. One fixture that
we call directly quite a lot is `fake_uuid`. Since it just returns the
value of `sample_uuid()` we can either call that instead (where we need
a fixed value) or generate a new UUID each time (where a fixed value is
not needed).
2/3 of our incomplete requests to go live are incomplete because the
Data Sharing and Financial Agreement isn’t signed.
We reckon we can be pushier about this by saying it’s ‘incomplete’ where
we know the agreement is signed.
Where the agreement is signed we should confirm this, rather than make
the line disappear. This is so it makes more sense to someone who sees
it as ‘incomplete’, signs it, then comes back to the page.
If we don’t know whether or not the agreement is signed we should wait
until someone has got in touch with us by requesting to go live to
figure it out. So that’s why we’re not showing that line at all.
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.
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.
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.
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.
If we’re going to be referring to email branding as part of the service
creation journey then we should make sure it doesn’t slow things down
too much by adding an extra API call. Caching things in Redis is a way
of avoiding unneeded API calls.
