Because we now[1] store info about each file upload separately in the
session the session isn’t overridden every time you upload a file. This
is good because you can do multiple file uploads idempotently.
Generally we are cleaning up after ourselves because we pop anything to
do with that upload from the session. However there is an edge case: if
you never send the file then the info about the file stays in the
session in perpetuity[2]. This is generally happening when people are
uploading files that are impossible to send, ie ones that have errors.
So this commit makes two changes:
1. remove info about a file upload from the session as soon as we know
that it contains errors
2. `POST` reuploads to the same endpoint as initial uploads because
otherwise we need to keep info about bad uploads in the session,
which would prevent us from doing 1.
1. https://github.com/alphagov/notifications-admin/pull/1968
2. or at least until the session is cleared by the user logging out
If you have a placeholder called `((phone number))` in your email
template, and you try to send a one-off message then the form input will
attempt to validate your ‘phone number’.
This is not helpful if you’re trying to put a landline number in your
email, for example.
This only affects messages being sent through the one-off interface.
This commit makes the form be aware of template type, which fixes the
problem.
we branch on any_ to either say "require ALL these permissions" or
"require ANY of these permissions". But we only ever call the decorator
with one permission, or with any_=True, so it's unnecessary
rather than allow admins to do everything specifically, we should
only block them from things we conciously don't want them to do.
This is "Don't let platform admins send letters from services they're
not in". Everything else the platform admins can do.
This is step one, adding a restrict_admin_usage flag, and setting that
for those restricted endpoints around creating api keys, uploading CSVs
and sending one-off messages.
Also, this commit separates the two use cases for permissions:
* user.has_permission for access control
* user.has_permission_for_service for user info - this is used for
showing checkboxes on the manage-users page for example
With this, we can remove the admin_override flag from the permission
decorator.
If someone has duplicate recipient columns in their file we don’t know
which one to use. This commit adds an error message which should help
them fix the duplication.
This commit doesn’t go to the extra effort to actually show the
correct values for duplication in the preview. Don’t think it’s worth
the effort/complexity for how infrequently we’ve seen this error.
Depends on:
- [ ] https://github.com/alphagov/notifications-utils/pull/376
Excel stores dates as floating point numbers, counting the days (or
fraction thereof) since 1900 (except when it counts from 1904).
However it also, incorrectly, recognises 1900 as a leap year. This means
that it’s ambiguous whether day 59 is February 28th, or February 27th,
depending if you’re counting up or down. In fact any number less than 60
is, therefore, ambiguous.
This shouldn’t really matter since no-one is going to be using dates in
the year 1900 in Notify messages. _Except_ when Excel misidentifies a
cell as containing a date. For example, if you have the number `9`
inside a cell, it means _house number 9_ if the next cell contains
_example_ street. but Excel is all like ‘oh they must want January 9th
1900!’ No. Bad Excel.
There’s not much we can do about this, but we can at least give people
an error message with the workaround, which is what this commit does.
Most of this commit message is paraphrased from:
http://xlrd.readthedocs.io/en/latest/dates.html
Done using isort[1], with the following command:
```
isort -rc ./app ./tests
```
Adds linting to the `run_tests.sh` script to stop badly-sorted imports
getting re-introduced.
Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because
I think it gives the cleanest diffs, eg:
```
from third_party import (
lib1,
lib2,
lib3,
lib4,
)
```
1. https://pypi.python.org/pypi/isort
Spreadsheets start at row 1 (the header row), and the values don’t start
until row 2. The row numbers in our URLs start at 0, which is a concept
that only makes sense to programmers.
It’s more predictable and consistent to make the number in the URL match
the row number displayed on the page when previewing the spreadsheet.
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.
This commit adds links to all but the currently-previewed row. Clicking
that link will populate the preview with values from that row. These
pages already exist; they were created in this PR:
https://github.com/alphagov/notifications-admin/pull/1696
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.
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.
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 picked an email reply to address, it’s good UI design to have
your choice played back to you, so you can be confident it’s worked.
This commit does that by making it part of the email preview.
Uses:
- [ ] https://github.com/alphagov/notifications-utils/pull/227
If you miss ‘postcode’ from your file then you get told that you need
‘address_line_1’, ‘address_line_2’, ‘address_line_3’, etc.
This is incorrect – the only required address columns are lines 1 and 2,
plus the postcode. So this commit corrects the error message to be
factually accurate.
We had a user report this to Fajer as a bug.
It’s useful to be able to play with the CSV upload thing and find out
how it works before you’re interrupted by the error telling you that
you’ve got as far as you can in trial mode.
We don’t want users in trial mode sending real letters. So we’ve
introduced an error message. This error message is also showing up when
users in trial mode and making a test letter (and having the knock on
effect of hiding the download button).
They should be able to make a test letter in trial mode, because it
doesn’t cost anything.
Telling users that they can’t send to more than 50 recipients in trial
mode doesn’t apply for letters (they can’t send to _any_ recipients).
So we should make sure that the error message about not being able to
send to any recipients always comes up instead of the 50 recipients one,
whether you’re trying to upload a file with 1 or 111 rows.
Users in trial mode haven’t signed the MOU. This means that they haven’t
agreed to pay for any costs they incur.
Unlike text messages and emails, we don’t give you any free allowance of
letters. Sending _any_ letters will cost the user money.
Therefore we shouldn’t let users who haven’t agreed that they will pay
for the service to incur costs by sending letters.
The pattern used for this is roughly the same as other trial mode errors
that we have already, ie a red box that says you’re not allowed. Not
sure if this is exactly right because it’s not exactly an error so the
pattern might feel too heavy-handed.
Getting this in place means we can turn letters on for users in trial
mode without worrying that they’ll accidentally send real letters, which
would result in:
- us having to absorb those costs
- some awkward conversations
This was causing a 500 in production.
This commit:
- reverts the code the working state it was before 68a1426e58
- figures out a way to make the tests pass without breaking the actual
app
- confirms that mocking things is hard
There’s some weird interaction between the message attribute of the
exception and mocking.
Luckily there is an internal attribute – `_message` which doesn’t go
through all the magic.
If you have errors in your file then there’s stuff you’re not going to
see on the page. So this doesn’t need to be in the Jinja templates that
are only used when there are errors.
Basically the conditional stuff is moving up to the level above these
templates.
There’s no immediate feedback with letter jobs, unlike email or text
messages jobs where you see the numbers starting to tick over straight
away.
We need to reassure the user that the thing they asked us to do (send
letters) is underway. ‘Printing’ feels like the natural first state of
the letter-making process. So this commit adds a banner to tell the
user that printing is the thing that’s happening.
If sending SMS is disabled for a service, it should not be possible to
add or modify SMS templates. If a user tries to do this, they should see
a different page with a link to go back. The same thing should happen
with email templates.
