Trial mode should let you preview the letter the same as live mode,
except for being able to actually end the letter.
Showing the recipient helps people understand how the feature works.
The recipient of the letter now displays at the bottom of the page when
previewing a valid letter. The template preview `/precompiled/sanitise`
endpoint returns the address, but we format it to display on a single
line with commas between each line. We also need to convert the
recipient address to ASCII so that it can be stored as S3 metadata.
We mostly rely on the API returning a 404 to generate 404s for trying
to get things with non-UUID IDs. This is fine, except our tests often
mock these API calls. So it could look like everything is working fine,
except the thing your passing in might never be a valid UUID, and thus
would 404 in a non-test environment.
So this commit:
1. uses the `uuid` URL converter everywhere there’s something that looks
like an ID in a URL parameter
2. adds a test which automates checking for 1.
We weren't checking if a service was in trial mode when they try to send
an uploaded file. If a service is in trial mode, we now show a banner at
the top of the preview page and no send button.
The overlay was showing for any invalid pdf - we only want to show the
overlay for invalid pdf files where there is content outside the
printable area.
We now use the pattern of showing a box at the top of the page with the
error. The error message has a heading and can have additional details.
Error messages and the invalid pages get stored in the S3 metadata.
We had been storing whether or not a file was valid in the S3 metadata,
but using the query string of the URL to store the original filename
and the page count. This meant that if you tried to view the preview
letter page without the query string you would see a `500`. It was
possible for this to happen if you were signed out of Notify while on
the preview page - you would be redirected back to the preview page but
without the query string, causing an error.
Added a send button which only appears on the page if the query string
indicates that the PDF is valid. Before actually sending, we check that
the service has the right permissions and that the metadata for the
letter confirms the letter is valid (because the query string can be
changed).
This sanitises uploaded letters and stores the sanitised result in S3
with if it passes validation or the original PDF in S3 if validation
fails. A metadata value of 'status' is set to either 'valid' or
'invalid'.
This checks that the PDF file is not malformed in some way (e.g. by
missing the EOF marker). We check this by trying to get the page count
of the letter which will be needed to display the preview of the letter.
Added a form to upload a single letter. Currently this only uses the
form to validate that a file is submitted and that the file is a PDF. If
either of these validations fail, the form will display an error.
Otherwise, we redirect to a new preview page which just has the filename
as the heading for now.
The uploads hub is just a page with text for now - there are no actions
available on the page. It is linked to from a new 'Uploads' menu item on
the left of the page which is only visible if your service has the
`letter` and `upload_letters` permissions and if the current user has
permissions to send messages.
