Our get_notifications fixture tries to be too clever and work out which
fields to return based on what arguments it’s called with. This is very
indirect and makes the tests less specific.
In other places we call the mocking code directly with arguments that
make it more explicit what the mocked response should be. This commit
does this for tests that we’d otherwise have to make changes to the
fixture for, because postage can no longer be `None` for letter
notifications.
Now that scheduled jobs are mixed in with regular jobs it looks weird
for the sort order to be different. This makes the sort order
consistently go from furthest in the future to furthest in the past.
The old sort order made sense when scheduled jobs were displayed
separately on the dashboard.
The uploads and jobs page should start showing in the _Uploads_ menu on
the left hand side.
If you’ve navigated to a job from the uploads page (ie you haven’t got
to that page because you’ve just sent the job) then you should see a
link back to the uploads page.
Notifications won’t exist for a job if:
- it’s just started
- it started a long time ago (older than the retention period)
We have a bug where:
1. Job starts processing, puts notifications on queue
2. Job finishes processing, sets status to `finished`
3. First notification gets picked up off the queue and put in the
database
In between 2. and 3. it’s possible for a job to be finished, but also to
have no notifications. We’re saying this is because the notifications
have been deleted, whereas really it’s because they haven’t been created
yet.
This commit fixes that bug by introducing the concept of recency for
jobs.
‘Recent’ is defined as 1 day, which is:
- a lot longer than it takes to create any notifications
- a bit shorter than anyone’s retention time
N.B. `processing_started` is defined here:
879ba1d5f0/app/models.py (L1194)
It can be `None` for scheduled jobs that haven’t started yet.
This follows the pattern of what we’ve done with services, users and
events.
It gives us a way of neatly instantiating a model for each item in the
list we get back from the API and reduces the complexity of the view
layer code.
Now is a good time to do this because we’re going to be making a bunch
of changes to the jobs pages, and those changes will be easier to code
and understand with a sensible model behind them.
This follows the pattern of what we’ve done with services, users and
events.
It gives us a better interface to the data we get back from the API than
dealing with the raw JSON directly.
Now is a good time to do this because we’re going to be making a bunch
of changes to the jobs pages, and those changes will be easier to code
and understand with a sesnsible model behind them.
The statement `page.select('[download=download]')` was returning an
empty list because the link on the page has an empty `download`
attribute, rather than it being set to the string `download`.
This commit:
- updates the assertion to find the element on the page
- makes the test more specific by checking where the link goes to, not
just its exists or lack thereof
You can click the blue boxes to filter the list of notifications. Once
the notifications have gone there’s nothing to filter, so we should just
show the numbers but without them being clickable.
Notifications could be missing because:
- none have been created yet
- they’ve been deleted
This commit adds separate error messages for each case, rather than a
less helpful generic one.
We work out how complete a job’s processing is by looking at how many
notifications have been created.
Later, we deleted all the notifications, according to the data retention
schedule. This makes it look like the job has gone back to 0% processed.
This commit accounts for this by not showing the % complete message once
a finished job has had its notifications deleted.
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.
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.
For scheduled files we say ‘sending today at 5:00pm’ or ‘sending
tomorrow at 11:00am’. But once we’ve started processing these files we
say ‘Sent 27 September at 5:00pm’. This makes it sound like 27 September
is not today.
This commit makes the dates shown on the dashboard consistent, by saying
‘today’ and ‘yesterday’ instead of absolute dates.
Also add more tests for showing or not the cancel those letters link
Also check if all notifications already in database
Upgrade delete button text logic to handle more cases
Also corrections following review
When looking at a notification you can either be coming from the page
of all notifications, or from a job. Currently the back link always
takes you to the page of all notifications.
This commit makes it a bit more sophisticated so if you’ve come from
looking at a job, you go back to the job.
It:
- saves repetetive boilerplate code
- does some extra checks (eg checking for a `200` response)
- makes the codebase less confusing to consistently do the same thing in
the same way
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.
Adds caching for service data retention. This removes separate API
client methods to retrieve individual data retention records by id
or type in favor of a single method that fetches and caches all
retention settings configured for the service. This makes it much
easier to invalidate cache when settings change.
Lookup by id or type is provided by helper methods in the service
model.
This was always showing the text 'Your letter has been sent...' This has
now been updated to start 'Your letters have been sent...' if a job has
more than one notification in it.
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)
A platform admin form accepts a list of references (one per line)
received from DVLA and sends them to the API to update notification
statuses.
References we get from DVLA start with `NOTIFY00\d`, which isn't
part of the reference we store in the database, so we remove them
before sending the data to the API.
The new `returned-letter` status should be treated as `delivered`
for now until we decide a way to display returned letters to users.
It’s useful to be able to see what the email or text message looks like,
especially if you’ve sent it with a test API key (so it isn’t in your
inbox or on your phone). We already have the page for this, so we just
need to link to it.
