Only users who work for government can accept the terms of use. This
will save us from having to email these requesters back telling them
they need to find someone else to submit the request.
There’s a lot of code in service settings which:
- talks to the API directly through the clients
- passes that information through to the Jinja template
By encapsulating this logic in the service model:
- the Jinja template can access the data directly
- the logic can be reused across multiple methods
Making people use a property is a sure way to make sure they’re spelling
the name of the property correctly, and allows us to easily swap out
properties that call through to the underlying JSON, and properties
which are implemented as methods.
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 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.
We sometimes have to do this over support tickets as part of the go-live
process; now we’re directing people to add a sender (as part of the task
list) we can explain what it is in context.
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.
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
