Users come to this page from various places, including the new 'Sign
the…' link on the request to go live page.
Of these users:
- some won't have signed it
- some will have signed it
- some will see that it's complete and wonder why, as they haven’t
actually done anything
So it’s more appropriate for the title of this page to be descriptive,
rather than an action.
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 duplicates how the task list pattern is coded in the GOV.UK
Prototype kit[1]. It adds ARIA attributes and the use of a
semantically-meaningful element (`<strong>`) to give more information to
screen reader users.
1. https://govuk-prototype-kit.herokuapp.com/docs/templates/task-list
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.
This will stop us repeatedly forgetting to add `novalidate` and
`autocomplete='off'` to our forms (which is how most of them are set
up).
It uses sensible defaults, based on how we most-commonly configure
forms:
- most of our forms are `post`ed (but this can be overridden)
- `autocomplete` should only be enabled where it makes sense, otherwise
it’s more annoying than useful (but this can be overriden)
- we should never be using HTML5 form validation because our own error
styles and messages are better
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.
