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
According to gunicorn `timeout` docs, async workers shouldn't be
terminated after the request time exceeds the specified timeout
as long as the worker process is still communicating.
This makes sense for async workers since they generally don't
block other requests from processing.
This is the behaviour we've seen on notifications-api - requests
can sometimes take much longer than the default 30 second timeout
and still succeed.
For the admin app however gunicorn has been shutting down workers
after 30s with `[CRITICAL] WORKER TIMEOUT`. This results in a 502
response from the admin app. Most of these requests fail because
the underlying requests to the api is taking longer than 30 seconds,
however we haven't seen this in the logs originally since unlike
the admin app, api requests succeed (even though their response is
no longer needed).
This seems like a bug in newer versions of gunicorn, downgrading
it to the version that the api is currently using solves the problem
by allowing admin requests to take longer than 30 seconds.
(Tested by trying requests with a `time.sleep(30)` locally).
It's not clear what exactly the bug in gunicorn is, but this also
potentially unblocks eventlet workers and allows them to process
more than one request at a time.
