This commit:
- uses WTForms email fields wherever we collect email addresses
- makes sure we don’t let the default HTML5 form validation get trigged
(using `novalidate`[1])
We don’t want to use the default validation because:
- it looks out of place
- it’s not well supported by assistive technology
1. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/form#attr-novalidate
Entering, or reading back sequences of digits is easier when they’re a
bit more spaced out.
This is because we read words as shapes, but read numbers
digit-by-digit.
So this commit adjusts the tracking of the type to put a bit more space
in for textboxes that are going to accept digits.
We started tracking upload errors in eb264f34b7
This has been useful.
This commit adds tracking of other form validation errors, so we can
pick up if there’s a form field that’s causing people particular
trouble.
Also had to rewrite a very old test to look for page content in a
smarter way.
Notify is now available, as a pilot, to local government and the NHS. So
telling people that it’s only for government departments and agencies is
- wrong
- might stop them from signing up
The word ‘organisation’ matches what’s used on the list of services, and
on the hint text on the email field on the sign up page.
If you’re using inbound SMS then I reckon it’s useful to be able to
naviagate from one message to the context in which that message sits
(ie the conversation).
This commit adds that link.
This is maybe a stopgap until we do something more like chat, where you
can reply on the same screen where you see the conversation, but maybe
it turns out we don’t want to do that – lets see how this works.
Currently the only way of ‘replying’ to an inbound message is by
copy/pasting the phone number from the inbound page into the send one
off page. Rather than making people copy/paste, this commit puts the
phone number in the session, if the user is going through the new reply
flow.
If your service is receiving inbound messages, you might want to reply
to them. Without an API integration, the only way to do this is by doing
the send one off flow. But currently there is no direct link from the
page which shows the inbound messages.
So this commit:
- adds a link to a new page…
- …which shows the available (ie only text message) templates with which
you can reply
If you miss ‘postcode’ from your file then you get told that you need
‘address_line_1’, ‘address_line_2’, ‘address_line_3’, etc.
This is incorrect – the only required address columns are lines 1 and 2,
plus the postcode. So this commit corrects the error message to be
factually accurate.
We had a user report this to Fajer as a bug.
Frontloads the ‘not’ part of the message, and makes it shorter, so
it’s more likely to be read and understood. Also makes it fit better
with the new ‘Can’t be used to send letters’ message.
When trying to send letters using the API, the ‘team and whitelist’ key
is confusing. We don’t have addresses for your team members, nor is
there a whitelist for letter addresses. The actual behaviour is that
you’ll get an error if you try to use this key to send letters.
So, for services who have letters available, we should add a hint
telling users that team and whitelist is probably not the key they’re
looking for.
Pembrokeshire County Council
G Cloud Team
Government Whips' Office
DCLG Housing and Planning Data Collection Team
Returner team - Government Equalities Office
Most user will only have one reply to address. Which means they should
never have to worry about IDs. And if you only have one then you never
need its ID, because the last remaining address will always be the
default.
So IDs should only be shown when a service has created more than one
reply to address.
This required a bit of visual tweaking of the _user list_ pattern,
because its spacing wasn’t defined in a way that worked when only the
name of the thing, and not its details were shown on the page.
