We call the yellow things ‘double brackets’ on the frontend, not fields
or placeholders. This error message was a bit out of date.
Also refactored it to use the `Field` class; this code was probably
written before `Field` was factored out of `Template`.
If you copy and paste an email address into the sign in box, there’s a
chance you’ll also copy some leading or trailing spaces. This is
especially likely to happen if you’re doing this while using your
computer upside down.
If this happens, it never even gets as far as looking up the user,
because the form validation doesn’t consider a string with a leading
space to be a valid email address.
This commit makes sure that accidental spaces are handled, by removing
them before doing any validation or hitting the API to look up the user.
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.
Refactor csrf handler into the normal error handler area, and then add
some tests to make sure it does the right thing. Also, change it back
to a 400, because the 403 err page talks about being in the wrong
place, but this is about sending the wrong data through, even though
it's technically a 403. Will need to think about wording but this is a
fine first pass
- 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.
