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.
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.
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.
