Removed as part of refactoring the code to generate the graphs of
template usage on the dashboard:
4a226a7a29 (diff-cf78cb5c29a2d3c4d45b61d8617824b7L29)
Didn’t realise that they were used by the functional tests.
This commit puts them back while keeping the code reuse.
This was used on the old product page to do the graphic of three phones
showing three different messages. We don’t have this any more, so this
‘component’ is unused.
Also removes some unused imports which were a hangover from previous
versions of the product page.
Although we integration test the pages that depend on these, it’s
probably a good idea to unit test them as well, to make sure, for
example, that all the different statuses are counted when working out
how many messages have been sent from a template.
- ‘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.
Everything is fine and happy locally and on Jenkins.
Getting a `cannot import name viewkeys` error on AWS.
Based on some Googling, it’s possible that this will fix it.
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).
Gulp was spitting out a lot of noise about stuff being out of date. The
cause seemed to be our outdated version of Gulp SASS. This commit
upgrades Gulp SASS to the latest version.
Changes:
---
https://github.com/dlmanning/gulp-sass/compare/v2.3.1...v3.1.0
This is a breaking change because one of the underlying libraries
includes a breaking change. But looking at their release notes, it
doesn’t seem to affect any SASS features that we’re using:
https://github.com/sass/libsass/releases/tag/3.4.0
Problem
---
You make a minor typo, save the file and your Gulp process dies without
you realising. You then spend 5 minutes trying to work out why your
changes aren’t appearing, no matter what edits you make.
Solution
---
Catch errors raised in processing the JS/SASS files and log them,
without killing the process.
How
---
Use a handy plugin called
[Gulp PrettyError](https://www.npmjs.com/package/gulp-prettyerror).
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.
