- ‘messages sent per month’ is a better description of what will appear
on the page than ‘activity breakdown’
- ‘templates used by month’ instead of ‘this year’ for consistency
I think ‘usage breakdown’ still works for the remaining link – it’s more
than a monthly breakdown, it also breaks down the spend.
Doesn’t need to say ‘by month’ in the `<h1>`s themselves, because you
can see from looking at the page that it’s broken down by month.
If you’re filling out a form then it should be possible to submit it for
as long as you’re logged in. We keep you logged in for quite a long time
now. This is partly for people using assistive tech, who might be slower
to fill in forms, and partly for people who get distracted in the middle
of a task and come back to it later.
The expiry on our CSRF tokens was more aggressive (3600 seconds – 1
hour) than our sessions. This commit sets the CSRF tokens to not expire,
so in effect they last as long as the session.
Also tweaks the config to have CSRF on locally (to replicate production
more closely) and only disable it for tests (because it’s a pain to
grab the tokens in tests).
When we moved the ‘Switch service’ link out of the nav on non-service
pages it removed any obvious way of getting back to your service on a
page that doesn’t have the service navigation (the non-obvious way is to
click ‘GOV.UK Notify’ in the black bar).
So this commit adds a ‘Back to service’ link which does the same thing
as clicking ‘GOV.UK Notify’ (tries to send you to your last-used
service, sends you to the list of services if it can’t).
We keep seeing Chrome:
- autofilling the sign in form with a phone number in the email box
- autofilling the register form with an email address in the phone
number box
This is because Chrome tries to autofill what it considers to be a
_login_. It detects a login as being:
- a password field
- preceded by a text input field
On the sign in page the password field is preceded by a field which is
supposed to receive an email address. On the register page the password
field is preceded by a field that’s supposed to receive a phone number.
I suspect that this is why it’s missing the two up.
The solution to this seems to be to defeat Chrome trying to be clever,
and make it autocomplete based on the `name` of the fields instead (we
name them sensibly, e.g. `email_address`, `phone_number`). The way to
defeat it seems to be sticking a dummy `input` right before the password
field on the register page. This dummy input is hidden from the page and
from screenreaders, so a user should never know it’s there. but Chrome
will autofill it anyway, with whatever wrong value it wants to.
The tour teaches you how Notify works by letting you do a thing and then
showing you the effect of the thing you’ve just done – a text message on
your phone.
This is not as effective if you don’t get the text message quickly. It
breaks the association you make between what you’ve done on the computer
and what’s happening on your phone.
Slow text message delivery can happen if you’re doing a big job. We can
get around this by making your text message use the priority queue.
This was observed in the pilot research session yesterday.
The breaking change page temporarily holds the changes in hidden inputs
on the page. The messages content it gets from the `.content` property
on the subject. This is raw and not transformed in any way, so fine.
For the subject it gets the value from the `.subject` attribute on the
template. For email templates, this will be transformed to highlight
placeholders with `<span class='placeholder'>…`. This means that when
the change is confirmed, it’s this encoded version that gets sent to the
API. Which is bad, because we then save `<span class='placeholder'>` in
the database.
This commit changes the page to look at the `._subject` attribute
instead, which is the internal, untransformed version of the subject.
The support flow was using `yes` and `no` to mean emergency/not
emergency. But not in all places – in one place it was using
`True`/`False` instead.
We were treating anything other than `yes`/`no` as a non-answer, which
means ask the question again. Because of the `True`/`False` thing, there
was no way of the user providing a valid `yes`/`no` answer. Which means
that we just kept asking them the question again and again and they got
stuck in a loop.
For some reason we were rebuilding `new_template` as a dictionary,
without the `placeholders` attribute. This meant that we were never
actually counting the placeholders, just counting the length of `None`
and adding 1 to it.
So this commit fixes that, beefs up the tests, and makes sure that
everything is pluralised properly.
41fa158635 added a proper Jinja filter
for formatting lists, which was better than the previous macro-based
solution.
It didn’t, however, account for HTML properly. It did the default Jinja
thing of escaping everything. Since we render lists of placeholders
by putting HTML before and after each item, this didn’t work (the HTML
got escaped and appeared on the page).
So this commit does the escaping of HTML outside Jinja, in the
user-submitted bits of the input only, then passes the whole thing
through as a `Markup` instance which doesn’t get escaped by Jinja.
no actual template functionality yet - just the ability for services
that have letters enabled to edit a 10 line block that will go on the
top right hand side of their letters with contact information
We’ve had a couple of instances where teams have sent the wrong template
to a …number of users.
Sometimes templates can be very similar and only have slight variations
to tailor them to a specific subset of users. So identifying the right
template by sight can be difficult.
We know that teams do give their templates meaningful names, and use
these names in other tools (spreadsheets etc) to refer to the templates.
So putting the name of the template on the page where you’re about to
send all the messages seems like it’s gives people an easier way of
double checking that they’re doing the right thing.
I umm’d and ahh’d over the wording a bit, and think ‘Preview of…’ reads
the best. It looks a bit weird because most template names are Title
Case. I think it’s better than some ambiguous punctuation (eg ‘Preview:
Template name’ or ‘Template name – preview’).
Some examples of real template names:
- Preview of Example text message templates
- Preview of Online LPA payment application reminder
- Preview of Create user account
- Preview of Split journey - Unknown credentials
- Preview of Public user: application without supporting documents
- Preview of Renewal Survey – February
- Preview of CEX New adult
- Preview of Applications are closing tomorrow
- Preview of Your application result - if successful
> Scottish Enterprise is Scotland's main economic development agency
> and a non-departmental public body of the Scottish Government.
– https://www.scottish-enterprise.com/about-us
For some reason their email domain is `scotent.co.uk` (but it redirects
to www.scottish-enterprise.com on the web for the some reason
¯\_(ツ)_/¯)
