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 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.
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.
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
Right now we have separate pages for email and text message templates.
In the future we will also have a separate page for letter templates.
This commit changes Notify to only have one page for all templates.
What is the problem?
---
The left-hand navigation is getting quite crowded, at 8 items for a
service that can send letters. Research suggests that the number of
objects an average human can hold in working memory is 7 ± 2 [1]. So
we’re at the limit of how many items the navigation should have.
In the future we will need to search/sort/filter templates by attributes
other than type, for example:
- show me the ‘confirmation’ templates
- show me the most recently used templates
- show me all templates containing the placeholder `((ref_no))`
These are hypothetical for now, but these needs (or others) may become
real in the future. At this point pre-filtering the list of templates
by type would restrict what searches a user could do. So by making this
change now we’re in a better position to iterate the design in the
future.
What’s the change?
---
This commit replaces the ‘Email templates’, ‘Text message templates’ and
‘Letter templates’ pages with one page called ‘Templates’.
This new templates page shows all the templates for the service, sorted
by most recently created first (as before).
To add a new template there is a new page with a form asking you what
kind of template you want to create. This is necessary because in the
past we knew what kind of template you wanted to create based on the
kind you were looking at.
What’s the impact of this change on new users?
---
This change alters the onboarding process slightly. We still want to
take people through the empty templates page from the call-to-action on
the dashboard because it helps them understand that to send a message
using Notify you need a template. But because we don’t have separate
pages for emails/text messages we will have to send users through the
extra step of choosing what kind of template to create. This is a bit
clunkier on first use but:
- it still gets the point across
- it takes them through the actual flow they will be using to create new
templates in the future (ie they’re learning how to use Notify, not
just being taken through a special onboarding route)
I’m not too worried about this change in terms of the experience for new
users. Furthermore, by making it now we get to validate whether it’s
causing any problems in the lab research booked for next week.
What’s the impact of this change on current services?
---
Looking at the top 15 services by number of templates[2], most are using
either text messages or emails. So this change would not have a
significant impact on these services because the page will not get any
longer. In other words we wouldn’t be making it worse for them.
Those services who do use both are not using as many templates. The
worst-case scenario is SSCS, who have 16 templates, evenly split between
email and text messages. So they would go from having 8 templates per
page to 16, which is still less than half the number that HMPO or
Digital Marketplace are managing.
References
---
1. https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
2. Template usage by service
Service name | Template count | Template types
---------------------------------------|----------------|---------------
Her Majesty's Passport Office | 40 | sms
Digital Marketplace | 40 | email
GovWifi-Staging | 19 | sms
GovWifi | 18 | sms
Digital Apprenticeship Service | 16 | email
SSCS | 16 | both
Crown Commercial Service MI Collection | 15 | email
Help with Prison Visits | 12 | both
Digital Future | 12 | email
Export Licensing Service | 11 | email
Civil Money Claims | 9 | both
DVLA Drivers Medical Service | 9 | sms
GOV.UK Notify | 8 | both
Manage your benefit overpayments | 8 | both
Tax Renewals | 8 | both
There’s a good reason for having the ` ` – it stops GOV.UK Notify
being split across two lines (which could happen on a smaller viewport,
eg mobile). Gotta protect the brand.
Not good for the brand for it to be showing up in the page though 😬
This got broken as part of 3f41090a94
The label for a form should never have user-submitted content in it, so
using `safe` is fine.
> When the CSV is missing the header row, we get an error and the user
> will see "Sorry, we are experiencing technical difficulties..."
>
> We should return a better error message for the user.
– https://www.pivotaltracker.com/story/show/140668615
This was caused by an attempt to access the `first_recipient` variable
before it was assigned. It would only be assigned when there was at
least one row in the file.
Fixing this means doing two things:
- defaulting `first_recipient` to be `None` before looking in the file
- adding an error message for when we can’t extract any rows out of the
file (which is more nuanced than the file just being completely empty)
(There’s a nasty `sort` in the Jinja template because when there are no
rows in the file the order of the required column headers is not
deterministic.)
When a screenreader user navigates a table, they use the columns
headings to orientate themselves. A column heading of ‘1’ is not
helpful.
So this commit adds some hidden text for screenreader users, which tells
them exactly what the column contains: the number of the row in the
original file.
Did most of this work in:
https://github.com/alphagov/notifications-admin/pull/1118
> In pages specific to a service (e.g. dashboard and sub pages) the
> title needs to distinguish which service it applies to. This is mainly
> to give context to screen reader users who could be managing multiple
> services.
>
> Implementing this uses template inheritance:
>
> `page_title` includes `per_page_title` includes `service_page_title`
>
> ‘GOV.UK Notify’ is inserted into every page title.
>
> Pages that set `service_page_title` get the service name inserted too.
when a user enters their 2FA code, the API will store a random UUID
against them in the database - this code is then stored on the cookie
on the front end.
At the beginning of each authenticated request, we do the following
steps:
* Retrieve the user's cookie, and get the user_id from it
* Request that user's details from the database
* populate current_user with the DB model
* run the login_required decorator, which calls
current_user.is_authenticated
is_authenticated now also checks that the database model matches the
cookie for session_id. The potential states and meanings are as follows:
database | cookie | meaning
----------+--------+---------
None | None | New user, or system just been deployed.
| | Redirect to start page.
----------+--------+---------
'abc' | None | New browser (or cleared cookies). Redirect to
| | start page.
----------+--------+---------
None | 'abc' | Invalid state (cookie is set from user obj, so
| | would only happen if DB is cleared)
----------+--------+---------
'abc' | 'abc' | Same browser. Business as usual
----------+--------+---------
'abc' | 'def' | Different browser in cookie - db has been changed
| | since then. Redirect to start
> Users that allow their session to expire, or access a bookmarked link
> are told they need to "Sign in to access this page" - we should
> explain that it's because they've been away a while, so that they
> understand why they're being asked to log in again.
– https://www.pivotaltracker.com/story/show/140016919
The message we were showing before (Please log in to access this page is
the default message from Flask Login).
In order to stop this flash message from appearing, we need to override
the default handler for when a user is unauthorised. We’re overriding it
with the same behaviour, minus the flash message.
If you navigate deliberately to the sign in page it’s unchanged.
Content is Sheryll-approved.
When your CSV file is missing the recipient column (eg ‘phone number’
or ‘email address’) we give you a helpful error message telling you that
this is the case.
When we changed the recipient column to be columns, plural, we didn’t
update the code that generated the error message. So you would get
errors that looked this like this:
> Your file needs to have a column called ‘’
This commit fixes the error message.
The bars were sitting in a table cell with some right padding, so they
never extended all the way to the right. Making it right-aligned removes
this padding, then setting the text to left aligned keeps things looking
the same.
