Email auth is a new feature that currently we’ve only given to teams
who have contact us with a problem.
At the moment, we’re aware of all the teams that are sharing phone
numbers when they sign in. We think that in the future there will be
other teams who encounter this problem. So we should let them know that
they should contact us if they are having the problem.
At the moment we want to talk to teams before giving them access to the
feature, so that we’re confident it’s only going to teams from whom it’s
more secure than using a text message code.
- Updated tests and added a new mock_get_monthly_template_usage
- Deleted get_monthly_template_statistics_for_service
- Added new test to test the redirection of the old endpoint
Now that the page title for picking a sender/reply to has been improved,
I think these pages are also less clear than they could be.
This commit changes the page titles to (I hope) be clearer about what is
needed from the user on these pages.
Changing the `<h1>` in https://github.com/alphagov/notifications-admin/pull/1638
turned out to be quite confusing. The combination of the word
"recipient" and a selection of email addresses on the page was confusing.
This commit changes the page title to be much more explicit about what
is expected from the page, rather than what is consistent with the text
of the link that the user clicked.
Changing the `<h1>` in https://github.com/alphagov/notifications-admin/pull/1638
turned out to be quite confusing. The combination of the word
"recipient" and a selection of email addresses on the page was confusing.
This commit changes the page title to be much more explicit about what
is expected from the page, rather than what is consistent with the text
of the link that the user clicked.
If you’ve chosen a text message sender then it’s good to see
confirmation of your choice.
This replicates what we do when you choose an email reply-to address.
* if the service issuing the invite does not have permission to edit
auth types, don't let them do anything. This will stop them turning
existing email_auth users back to sms auth
* if the user hasn't got a mobile number, but the invite is for sms
login, don't do anything either. They won't have a phone number if
they signed up via an email_auth invite previously.
in these cases, we accept the invite and add the user to the service
as normal, however, just don't update the user's auth type.
If we’re going to ‘disable’ radio buttons then we should always tell
users why the radio button is disabled.
This is what we found with the API key choices anyway.
Google tries to auto-generate a snippet of a site’s content to show in
search results. Currently it’s not doing a great job of this for Notify.
There’s a chance that if we give it better content in the site’s meta
description then it will use that instead. Worth a go…
The content is adapted from the blue box on the product page.
It’s 145 characters, which is within the 160 characters recommended[1]
It matches the content in the page, and contains words that users are
likely to be searching for (GOV.UK Notify, emails, text messages).
It’s only on the homepage, because it shouldn’t be duplicated across
multiple pages.
https://yoast.com/meta-descriptions/
We have a sort of principle that when clicking a link, the page you land
on should be titled the same as the link you clicked.
This also reduces unnecessary repetition between the page title and the
form label.
Make it clear that:
- In the case of text messages, it’s about who the message comes from
- In the case of emails, it’s about where the user will reply to
If you’ve spelt ‘postcode’ wrong, or missed only ‘address_line_2’ then
it’s pretty noisy to be told that your file needs columns called address
line 1, address line 2, and postcode.
It’s better to be specific about which column you need to fix in order
to get past this error. As a principle, we’ve found it better to tell
get people to fix one error at a time, rather than overwhelm them with a
list of errors to correct – this is why we split the recipient column
errors out separately in the first place.
Numbers over a billion overflow the two column layout. Numbers over one
hundred thousand overflow the three column layout.
This commit makes the type size smaller in these cases, so that the
numbers still fit in the boxes.
the update_user fn was used in two places, for things that are handled
fine by update_user_attribute. Reduce complexity in the API by killing
the PUT, which is more dangerous (might silently overwrite things that
shouldn't be, like "last_logged_in_at" etc).
Had to change the code not received mobile number form, and the
activate user function.
the update_user fn was used in two places, for things that are handled
fine by update_user_attribute. Reduce complexity in the API by killing
the PUT, which is more dangerous (might silently overwrite things that
shouldn't be, like "last_logged_in_at" etc).
Had to change the code not received mobile number form, and the
activate user function.
