This changeset converts the display of dates and times to be just UTC to match the recent changes in the backend. This unwinds a bit of work that was done previously and allows us to start with a clean slate in how we want to approach displaying dates and times going forward. It also adds a bit of explanatory text to help users.
Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
Co-authored-by: stvnrlly <steven.reilly@gsa.gov>
* Updated header and footer
* Moved files around and updated gulpfile to correct the build process when it goes to production
* Updated fonts
* Adjusted grid templating
* Adding images to assets
* Updated account pages, dashboard, and pages in message sending flow
* Updated the styling for the landing pages in the account section once logged in
The only impactful change is the major version itself, where I've
fixed the breaking changes due to the upgrade of PyPDF2 [^1] and
checked there are no deprecation warnings when I run the tests.
[^1]: https://github.com/alphagov/notifications-utils/pull/973
We added a new argument to `client_request.get` and
`client_request.post` to specify that it should return a raw `Response`
object rather than an instance of `BeautifulSoup`.
This is useful because sometimes we need to look at stuff like the
response headers.
However it turns out we already have a separate method for this, so
rather than invent something new I think it’s better to stick with the
thing we already have.
We have a `client_request` fixture which does a bunch of useful stuff
like:
- checking the status code of the response
- returning a `BeautifulSoup` object
Lots of our tests still use an older fixture called `logged_in_client`.
This is not as good because:
- it returns a raw `Response` object
- doesn’t do the additional checks
- means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')`
This commit converts all the tests using `logged_in_client` to:
use `client_request` instead.
If a letters that has been posted via the API has more than 10 pages it would not get a validation-failed status. This also happens for letters in a CSV upload, only the first row has been validated for having too many pages, because you need to created the pdf before getting an accurate page count.
The API has been updated to mark these letters as invalid and move the
letter to the invalid s3 bucket, the meta data is also set with the
error message and page count.
This PR updates the notification page to display the validation error.
https://www.pivotaltracker.com/story/show/169209742
is unable to print the letter we need to mark the letter as failed.
If we mark the letter as a technical-failure, we say that we will fix
the issue, which is wrong because we can not fix the issue.
If we mark the letter as validation-failed, the letter is in wrong
bucket so the letter is not viewable/downloadable by the client.
This PR updates the message for a letter marked as permanent-failure to
better reflect what has actually happened.
If you’ve come to look at a notification via the uploaded letters page
then the ‘< back’ link should take you back there, not to the usual
activity page.
We had a report that when clicking on the 'Download this letter' link on
the notification page the file was not being downloaded as a PDF file
but was given a `.htm` file extension instead. We should be able to stop
that happening by using Flask's `send_file` function with the right mimetype.
This change updates the `view_letter_notification_as_preview` to use
`send_file` and splits out code to get the file data into a separate
function.
Mocks in the tests have been updated and some unused mocks removed.
The postage covers up some of the letter, so it can hide the problem. It
also implies that the letter has been put in an envelope, which will
never happen if it fails validation.
This matches what we do for uploaded letters.
This is a friendlier and better way of showing dates anywhere except in
a report which might be archived and referred back to later.
Bit trickier to implement here because a dat requires ‘on’ beforehand,
but we don’t say ‘on today’ in English.
This helps people understand how delivery dates fit into the week,
because if sending a letter spans the weekend it will take a bit longer.
We can remove `|string` now because `utc_string_to_aware_gmt_datetime`
now accepts datetimes.
We show letter validation errors in two places:
1. In response to a user uploading a PDF
Here we use the error banner pattern because the problem is as a
direct consequence of a user’s action, and is blocking them from
continuing.
2. Once a PDF provided through the API has been validated
We use a less prominent pattern of red text with no border because
the message is reporting on something that’s already happened, and
which wasn’t a direct consequence of the user clicking something
Because the context and patterns used are different we need slightly
different content in each of these situations. Previously we tried to
reuse the same content to make the code cleaner and less repetitive. But
ultimately a clear interface trumps clear code.
Before deploying a change to template-preview to return a validation error for letters that are missing the address block, we need to add the new erorr message to admin.
Some content changes have been made to other messages.
The format of the message has changed.
Instead of using `mock_get_notification` to create a notification then
mock it in the tests, a new function, `create_notification`, can be used
to create a custom notification to be mocked. Using this in the
`test_notifications.py` file makes it Pytest 5 compatible.
We were using user fixtures in a lot of parameterized tests, but this is
no longer allowed in Pytest 5. To avoid having to split up the parametrized
tests (which would make the test files a lot longer and slightly more
difficult to read) this commit creates functions which return various types
of user json so that we can use these as the test parameters instead.
Show valdiation failed messages on letter notifications in red text,
not in the banner like we do on Uploads and Validation checker pages.
This is because it is a different step in the journey: the user
has already sent the notification and styling needs to be in line
with other places where user is checking the notification she already
has sent.
