The activity page was AJAXified in
https://github.com/alphagov/notifications-admin/pull/952 but this
didn’t take pagination into account.
So if you visited page 2, the contents of the page would be replaced by
Javascript with the contents of page 1. So you’d never be able to see
anything beyond page 1, expect for a brief fraction of a second when the
page loaded.
This commit makes sure the AJAX request uses whatever page parameter is
in the URL of the original page.
If you schedule a job you might change your mind or circumstances might
change. So you need to be able to cancel it. This commit adds a button
on the job page which hits the `…/cancel` API endpoint for a job.
The information about a job doesn’t make sense if a job is cancelled.
We could change the information to reflect that the job won’t be sent/
wasn’t sent/was cancelled, but there’s nothing you can really do with
this info.
So instead let’s:
- hide cancelled jobs from the dashboard
- hide cancelled jobs from the jobs page
- 404 the page if the user tries to click back enough times to hit the
job page
If a job is scheduled then we can’t show the notifications yet, and the
progress report will stay at 0%.
In their place we should show what time a job will start.
Later on (when the API is ready) this area of the page should also show
a cancel button.
On the dashboard:
- adds a new ‘in the next 24 hours’ section to the dashboard which lists
upcoming jobs
- tweaks some spacing on the dashboard so that it doesn’t look like too
much of a mess
- don’t show scheduled jobs in the table of normal jobs
On the jobs page:
- don’t show scheduled jobs
The job is complete when all notifications are delivered or failed.
The report is complete once we have all notifications are in the
database.
This commit changes the meaning of the percentage from the former to the
latter. This is how it was before we removed the aggregate stats for
jobs.
Slicing was to avoid duplicate items in the list. A more idomatic way
to avoid duplicate items in a list is to use a `set` instead.
The order of the list doesn’t really matter, but it’s a lot easier to
test for if the order is consistent.
The CSV report isn’t very useful until it has all the rows from your
original file. So we shouldn’t show you the link until all notifications
have been created.
Until this point, it’s useful to know how much longer you need to wait,
so this commit adds a percentage count of how much of the file has been
processed.
The difference between created and sending isn’t something a user should
have to care about. So this commit:
- counts created and sending as the same thing
- displays and notifications which have a status of created as sending
Processed is not an easy to understand thing, and the overlap with
sending/delivered/failed is not easy to intuit.
‘Total’ is a much easier concept to grasp (it relates directly to your
file), and it’s less distracting because it doesn’t change.
It’s weird when the sending number ramps up to ~200 or so and then
just floats around as new rows are being added and older ones are being
marked as delivered/failed.
It’s also not great that you don’t know how many rows are in a file, if
you haven’t uploaded it yourself. But the only reason you want to know
this is to know how much work Notify has remaining to do.
So ‘sending’ should start from the total number of rows in the file
and count down.
to help get rid of notification statistics tables, move over the
job page. fortunately its required data format is almost identical
to the return value of the detailed service endpoint, so little
work is required - only to add a sending column
When we say ‘delivery information is available for 7 days’ you have to
infer _when_ the seven days starts. When you come back to the page it
still says ‘available for 7 days’ even if you only have a day left to
download it. This is confusing.
This commit changes the text to be relative to now, eg ‘available for 7
days’, ‘available for 1 day’.
The date is counted to midnight on the seventh day, which is when the
data is actually deleted.
Our templates are a littered with `request.args.get('help', '0')`.
This commit refactors these into a single helper method, which can be
used by the view functions, then passed to the template.
This makes the templates cleaner, and should make it easier to refactor
`help` out of the query parameters entirely in the future.
This commit extends the `ajax_block` component to take a `dict` of
partials, from which it can select the partial matching its `key`
argument and print its HTML to the page.
This means that the same markup is only rendered in one place, rather
than in two (individually in the JSON endpoint and as `include`s in the
parent template).
This is less repetitive than typing out the HTML with all its attributes
every time.
It also lets us wrap up the idea of ‘finished’ as a parameter, so the
AJAX code will only be initiated when it’s needed, eg if a job is still
processing.
We can filter all notifications by status already. This commit reuses
the same code to filter the notifications for a job by status.
This means that, visually we can show the count on a job the same as
we do for all notifications, which is similar to how we show the counts
on the dashboard, so hopefully it feels like a bit more of a solid
thing.
This also applies to CSV downloads and AJAX updates, which will inherit
any filtering that their parent page has applied.
We can filter notifications on the activity page by state.
This commit adds counts to those filters.
This is mainly so that we can consistently do the same thing on the job
page later on.
The graphs of template usage feel a bit weird to me now.
1. They are counts of messages, but the numbers are very small
not big like we do everywhere else (eg the counts on a job)
2. There’s a lot of blue, especially for something that you can’t
click
This commit makes the numbers bigger and the bar chart grey.
- _Processed_ is all the notifications that we know about, ie sending,
failed and delivered
- _Sending_ is notifications that we have either put into a queue or are
waiting to hear back from the provider about.
The big numbers on the dashboard are a count of all the messages we’ve
processed. So when you click them, the table of notifications you see
on the dashboard should contain that number of notifications.
This also gets the activity page one step closer to being like the job
page:
| Before | After
---------|----------------------------|---------------------------------
Activity | Sending, failed, both | Processed, sending, failed, delivered
Job page | Sending, failed, delivered | Sending, failed, delivered
The link to download a CSV of notifications looks like
`/endpoint?download=csv`. This not not very web idiomatic.
The service manual recommends:
> Only use query strings for URLs with unordered parameters like options
> to search pages.
The CSV is a different representation of the same data, it does not
perform searching or filtering on the data.
The proper way (as we do elsewhere in this app) is to put an extension
on the endpoint to indicate an alternate representation, eg
`/endpoint.csv`
This commit splits the activity page into two pages, one for emails
and one for SMS.
Technically this means moving from having template type in the
querystring and putting in it the URL, eg:
*Before*:
`/services/abc/notifications/?template_type=sms`
*After*:
`/services/abc/notifications/sms`
This commit changes the activity page to only have controls
