Sometimes people print stuff under where we’re folding the letter. It’s
annoying to not be able to see it.
This commit adds a little detail where, once you’ve sent the letter
you can unfolds the corner to see what’s underneath.
It’s better that we do this for all letters for discoverability.
It’s inaccurate to have an estimated delivery date for letters sent
using a test key. We shouldn’t reassure people that:
- the letter won’t be printed
- (in the case of precompiled letters) that the letter has passed
validation
If PDF files have a validation error which means that they can't be
opened by PyPDF2 we would previously show the 500 status error page. We
now catch PyPDF2.utils.PdfReadErrors so that we can display a custom
error message on the notification page instead.
Added a link to cancel letters from the letter notification pages if the
letter is still able to be cancelled. Clicking on this link will show a
confirmation box, and will then cancel the letter if the user confirms.
In the long term, we don't want to show cancelled letters. But for now,
this changes cancelled letters to display in the same way that letters
with a status of permanent-failure, since we are currently giving
letters that we want to cancel the status of permanent failure.
This commit adds content pages for the notifications pages, particularly
the letter pages, which will make things clearer now that we will soon be allowing
letters to be cancelled.
The main changes are:
* The confirmation banner for letters sent from a CSV file now states when
printing will start.
* We state the CSV file that notifications were sent from on the
notifications page
* The notification page for letters shows when printing starts (today,
tomorrow, or that date that the letter was printed)
Don’t think it’s necessary. Makes things consistent with the sent letter
page, which only says ‘Download as a PDF’.
This inconsistency would be more glaring now these pieces of text appear
in the same place, in adjacent steps of a journey.
This makes its positioning consistent with the previous page in the
one-off sending journey.
It gives us more space to put information about the status of the letter
above the preview of the letter.
We’ve moved away from using the expand/collapse pattern on the page
where you click ‘send’. Instead we’re putting the send button in the
sticky footer.
So it’s a bit jarring to still have the expand/collapse on the page you
see after you’ve sent an email. This commit replaces it with the sticky
footer as well.
This is only relevant for emails because:
1. Text messages are generally short enough to fit on the screen
2. We don’t show the status of letters because they don’t really change
In trial mode you can’t send letters. But it’s still useful to be able
to build up a letter to see how it work.
Best place to put this error is before someone tries to send a letter
for real.
At the moment we show precompiled letters that have failed the
validation as having been sent. This is confusing.
We should communicate it as having been cancelled (rather than failed),
with the implication being that Notify has come along and cancelled the
letter before printing it. I think this is conceptually what makes the
most sense.
From the user’s point of view any letters that show up as cancelled
probably need to be fixed and resent, so it makes sense to group them
with the same name.
At the moment we are manually cancelling letters for people when they
ask us to. Once’s we’ve done this there is no indication that it’s
happened except for the date going red on the list of letters.
This commit adds some error messaging and styling to show when a letter
is cancelled.
Letting people cancel their own letters will be a future enhancement.
The one downside of skipping the template page is that you no longer
get such strong confirmation that you’ve picked the correct template.
You still see the preview of the template, but it’s further down the
page, and the name of the template has disappeared.
This commit adds the name of the template to the page title, to:
- have some continuity from the previous page
- make it easier to double-check you’ve chosen the correct template
At the moment you can’t press refresh on the check page if there’s
errors. This is because the session gets cleared when there’s errors.
This is a bad user experience.
The data that this page is relying on (from the session) is:
- template ID
- original file name
Neither of these things need to be in the session because:
- they are not secret
- the user can modify them already (by choosing a different template or
renaming their file locally)
So this commit additionally stores them in the URL.
Both `<button type='submit'>Submit<button>` and
`<input type='submit' value='Submit'>` can be used to submit a form.
We have historically[1] used `<input>` because it’s better-supported by
IE6 in that:
- the `submit` attribute is mandatory on `<button>`, not on `<input>`
- the `innerHTML` of a button will be submitted to the server, not the
value (as in other browsers)
Reasons to now use `<button>` instead:
- IE6/7 support is no longer a concern (especially with deprecation of
TLS 1.0 on the way)
- Because an `<input>` element can’t have children, the pseudo-element
hack[2] used to ensure the top edge of the button is clickable doesn’t
work. We’re seeing this bug[3] affect real users in research.
1. We inhereted our buttons from Digital Marketplace, here is me making
that change in their code: 8df7e2e79e (diff-b1420f7b7a25657d849edf90a70ef541)
2. 24e1906c0d (diff-ef0e4eb6f1e90b44b0c3fe39dce274a4R79)
3. https://github.com/alphagov/govuk_elements/issues/545
We should standardise on <a download> rather than
<a download="download"> everywhere. The value of the download attribute
tells the browser what filename to use, but is overridden by the
Content-Disposition HTTP header. Since it’s not being used, we should
remove it for the sake of disambiguation.
If you’re using inbound SMS then I reckon it’s useful to be able to
naviagate from one message to the context in which that message sits
(ie the conversation).
This commit adds that link.
This is maybe a stopgap until we do something more like chat, where you
can reply on the same screen where you see the conversation, but maybe
it turns out we don’t want to do that – lets see how this works.
When I split up the error messages on the check CSV page into multiple
templates, I also reduced the repetition of wrapping `<div>`s and macro
calls by moving them up outside the conditional blocks (see
8e947f315d).
Unfortunately I didn’t make the same adjustments for the one-off flow,
which meant that errors on these pages lost their styling. This commit
re-adds the styling for these error messages.
The status won’t ever change from sending for letters. For now at least.
And even when we do come up with more useful statuses I’m not convinced
it’s useful to expose them to our admin users.
A more useful piece of information to show is when we think the letter
will be delivered.
they're currently expecting a RecipientsCSV object - but we won't
always have that available if we're handling a single notification.
So make the partials take generic variables, and then use a jinja with
block to pass in the correct values from either the check csv page or
the check notification page.
Additionally set the notification check page to show errors nicely -
hide the send button if there were problems, and replace the header
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.
‘Report’ jobs are what we used to have for one-off messages. The page
for a report job doesn’t contain any extra info from what’s on the
notification page. We will still have ‘Report’ jobs while we transition
to sending one-off messages through the API. So while we still have
these jobs, let’s hide any links to them because they’re not useful
pages.
If a notification has been sent from a job then that’s important context
to know about it. So we should surface that information on the page.
It also gives users an easy way of going back, if that’s the page
they’ve come from.
