Email addresses in invites should be case insensitive. This is to stop
the bug where a user creates their account using a lower case email
address (e.g. user1@gov.uk), but is then invited to a service using
their email address in a different case (e.g. USER1.gov.uk) and sees
an error message telling them that they can't accept an invite for a
different email address.
Because exceptions can be expensive performance wise (see:
https://docs.python.org/3/faq/design.html#how-fast-are-exceptions).
Since we’re counting the number of rows anyway this doesn’t introduce
any performance overhead there. And I think it’s equally readable/same
number of lines of code.
We’ve heard from some users, especially those sending letters, that
they’d like to check that a spreadsheet they’ve uploaded has populated
the template correctly.
My reckon is that seeing just one row of the spreadsheet populate the
template isn’t enough to give people confidence that everything’s
working properly. So this commit is the first step towards being able
to preview an arbitrary row of a template, by extending the URL
structure to optionally accept a row number for pages or files (ie PNG)
that preview successfully uploaded spreadsheets.
What this commit doesn’t do is link to these pages; that will come as
part of a subsequent commit.
Since instances of `Recipients` are now iterable we can just look up the
first row by index, rather than having to hit the rows property as a
generator.
There is a chance that there won’t be a first row, if the file has 1 or
fewer columns. So we still need to handle a possible exception (albeit
it a different one to before).
This variable isn’t used by our Jinja templates. Presumably it was
from the time before instances of `Template` were responsible for
showing who the email/text message was being sent to.
Since we’re doing this globally, we don’t need to handle it in a custom
way for the sign in form (and it’s much nicer encapsulated like this).
Also added some more extensive tests in this commit.
We’ve had whitespace-in-emails problems on:
- register form
- sign in form
- send one off form
We should just handle whitespace gracefully, by ignoring it. Makes sense
to do this at a global level because there might be other places it’s
causing problems that we don’t know about.
The only place that users _might_ be relying on leading/trailing spaces
(and we have no way of knowing this) is in passwords or tokens. So this
filter ignores any instances of `PasswordField`.
Adapted from @pcraig3’s work on Digital Marketplace:
- 4b06f5cfb7
- e761c1ce65
Delivery comes before inbound. The order of the URLs was jumbled in two
places:
- in the view function
- in the Jinja template
So as the user saw it the URLs were in the right order, because the
double jumbling cancelled itself out. But it made the code _really_
confusing to read.
When viewing a letter template, there is a button to edit the letter
contact block. This should take the user to the page to edit the letter
contact block, but if a service has not set any letter contact blocks, the
button was returning a 404 error.
The code has now been changed so that if the service has no letter contact
blocks the edit button will link to the page to add a letter contact
block.
Pivotal story: https://www.pivotaltracker.com/story/show/152881444
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.
The features nav is supposed to navigate your between pages in the app.
It’s very unexpected to have it open an external link.
Performance isn’t strictly a part of Support, but it’s worked having it
there for long enough that it’s probably not a bother.
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
- Removed the code for the template_history endpoint and replaced with a
redirect to the new page so that anyone is forwarded on
- Updated the template to point to the new template_usage page
Re-organised the code to re-use the months array which also was not
displaying a month where there was no stats. This now gets the months,
enumerates that array updating the templates used when there are stats
items so the users sees each month of the financial year (even if there
are no stats) when there are stats they are displayed.
- When a year contains no data ensure a default set of months is
returned so that all months can be seen in the UI
- Add the template id so the user can click through to the template
The link which when clicked allows the user to view different financial
years was pointing to the template_activity page. Updated to the link
to point to the new page.
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.
