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.
I’m hoping that if I can design something that clearly differentiates
them then we won’t need to do so by putting them in separate tables,
which then need labelling, which would clutter up the page.
The logic around what gets shown on the uploads page was hard to follow.
This commit makes three changes to hopefully make it easier:
- remove the passing-around of a string containing the contents of a
rendered partial
- encapsulate everything in one `show_scheduled_jobs` variable, rather
than mixing between `scheduled_jobs` and
`current_service.scheduled_jobs`
- adds a comment to explain why we still render `_jobs.html` even when
we know we have no jobs
This is the same thing we do for caseworking users who don’t have the
dashboard. Since we’re going to summarise scheduled jobs on the
dashboard instead of listing them they need to be listed here instead
(which is where we’ll link to from the dashboard).
Design of this will probably evolve as we work out how to style single
letter uploads and letter jobs, but that’s OK for now because no-one
has the uploads page at the moment.
it just shows a h1, so isn't helpful for people. We can re-use the 500
error page, which includes instructings "Try again later" and
instructions on what to do next (check the status page, email notify
support).
this required refactoring to ensure we can show the 500 error page while
still returning the required status code
We had two templates that contained a link styled as an old style
button but that weren't being used anywhere (one would actually give a
`500` if you tried to visit it). This removes them and the view function
for one of them (the other no longer had a view function).
We’re going to start using the returned letters summary to show some
info on the dashboard.
This means we will be accessing it more often than it changes. And we
know exactly when it changes because it’s us manually submitting the
references we get from DVLA.
This makes it a good candidate for being cached, and Redis is where we
cache stuff that we’d otherwise go to the API for.
As per https://www.pivotaltracker.com/story/show/170796514 we want to make the delete template confirmation dialog box more consistent and clear.
The API has been updated with a new endpoint that only returns the last-used date, this date is more accurate since it goes to the ft_notification_status table, if the notification table is empty.
I ended up creating a new test user and logged_in_client, which isn't really great. But I tried adding a current_session_id to the active user in the test, but that broke all other tests.
I tried setting current_session_id in all the users being tested but that didn't work either. I'd like to come back to fixing the tests and reducing the number of conftest methods in another PR. For now this fixes the bug.
Anytime a user clicks "sign out" we should be signing them out server side as well. This can be accomplished by setting the Users.current_session_id = null.
I found that the method User.logged_in_elsewhere doesn't need to check if the current_session_id is None. The current_session_ids in the cookie and db (redis or postgres) then the user should be forced to log in again.
