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.
The following errors may happen:
* Number outside of service if service in trial mode
* Message too long for sms
* Service over daily limit
We need to handle these. They only return on send, rather than in a
separate validation step (for now).
where we were previously setting the placeholder when going through
the send self a test - however, should be setting recipient. Also,
only do this on step-0 of the one-off route, not the send-test route,
since step-0 of send-test is the first normal placeholder. Phew!
note: in the case of letters, we still want to create a CSV file. This
only modifies the code flow when it's an email or template 😩
renamed `send_test_values` to `placeholders` because a) that's what
they are and b) this isn't just for sending a test message any more
rather than creating a job, after entering the placeholders, you now
send a single notification. This means we don't clog up s3 by creating
lots of one line CSV files.
it's confusing reassigining one template (json from api) to another
type (utils object) on one line.
Also removed an unnecessary bounds check (since if placeholders is
empty the IndexError will throw on the next line anyway and it'll
be handled the same), and moved get_back_link out to its own function
‘One-off’ is a bit wooly. Feels like our name for the thing. ‘Send to
one recipient’ matches ‘Upload recipients’.
This also means making the `<h1>` on job page ‘Report’ for one-off
messages. It doesn’t make sense to call the feature ‘send to one
recipient’ when we’re not using the language of one-off any more.
It’s a confusing proposition to have two features which are almost
identical. Even differentiating between them in the template menu would
be tricky.
I think the better thing to do is rename the whole feature to ‘send
one-off message’.
Then if someone wants to use there own phone number or email address,
give them a quick shortcut to doing that, once they’re in the flow.
In the background this reuses the ‘send yourself a test’ code, but
the user is never aware that they’re going through a different route
to send an individual message. So the proposition stays nice and clean.
We have some fairly complicated nested if statements in our Jinja that
decide what the page titles should be. It’s only going to get more
complicated with the send individual message routes.
So this commit:
- moves the logic from Jinja to Python
- adds tests to check things are working as expected
- sets the page titles to the right thing for each flow
It would be annoying to get all the way to the end of the flow and get
told that the phone number or email address you entered isn’t valid.
So this commit reuses the existing WTForms objects that we have to do
some extra validation on the first step in the send one-off message
flow. It also accounts for international phone numbers, if the service
is allowed to send them.
It doesn’t reject other people’s phone numbers if your service is
restricted, because I think it’s better to let users play with the
feature – it’s good for learning.
This commit adds an extra, initial, step to the ‘send one-off message’
flow to ask for a phone number or email address. This is the first pass
at making a feature which caseworkers or similar could use Notify to
send individual messages while they’re working a case.
This commit adds a route which is identical to send yourself a test, but
with its own endpoint. This will let us add a slightly different
‘send a one-off message’ flow. This commit just adds the route though,
and makes sure that the tests pass for both routes.
Because we put the step in the URL, users could:
- skip ahead to a later step
- navigate to a step which doesn’t exist (ie an index greater than the
number of placeholders)
This commit adds some checks to do the sensible thing in the unlikely
event that either of these situations occur.
Calculating the number of pages in a letter is quite slow. And the send
yourself a test pages need to load _fast_. Since filling in placeholders
is very unlikely to change the number of pages in the resultant letter,
it’s pretty safe to cache that count, and makes the subsequent pages
load a lot faster.
The send yourself a test feature is useful for two things:
- constructing an email/text message/letter without uploading a CSV file
- seeing what the thing your going to send will look like (either by
getting it in your inbox or downloading the PDF)
- learning the concept of placeholders, ie understanding they’re thing
that gets populated with _stuff_
The problem we’re seeing is that the current UI breaks when a template
has a lot of placeholders. This is especially apparent with letter
templates, which have a minimum of 7 placeholders by virtue of the
address.
The idea behind having the form fields side-by-side was to help people
understand the relationship between their spreadsheet columns and the
placeholders. But this means that the page was doing a lot of work,
trying to teach:
- replacement of placeholders
- link between placeholders and spreadsheet columns
The latter is better explained by the example spreadsheet shown on the
upload page. So it can safely be removed from the send yourself a test
page – in other words the fields don’t need to be shown side by side.
Showing them one-at-a-time works well because:
- it’s really obvious, even on first use, what the page is asking you to
do
- as your step through each placeholder, you see the message build up
with the data you’ve entered – you’re learning how replacement of
placeholders works by repetition
This also means adding a matching endpoint for viewing each step of
making the test letter as a PDF/PNG because we can’t reuse the view of
the template without any placeholders filled any more.
Right now showing all the pages in full is the only way we have of
showing a letter that makes sense to our users. Maybe in the future we
show some kind of truncated version, but the end of the first page is
not a good place to truncate the letter.
This commit just extracts the code for showing multiple pages from the
template view, refactors it for reuse, and includes it in the send
views.
