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
we don't want to use the old statistics endpoints any more
also a couple of quality of life changes
* moves some logic out of the _totals.html template
* tidies up statistics_utils
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 banner was always being shown because the template was never
getting sent the service’s templates from the API.
This commit fixes this to only show the banner when a service has no
templates, and adds some tests to make sure it doesn’t happen again.
This changes it back to how it was when we first introduced this
feature:
https://github.com/alphagov/notifications-admin/pull/181
It’s kind of lost on the page where you upload a file, which is a shame
because it’s a good teaching aid.
After the tour we should ground users by dropping them on the dashboard.
In the background, we delete the example text message template. This
means that users start from a clean slate when they go to add their own
templates
This also means some wording changes to the tour so it still makes
(some) sense:
- 1, 2 and 3 should refer to the current step, not describe the next
one
- the link should take you to the dashboard
- change from ‘Get started’ to ‘Try this example’ because we’re using
‘Get started on the dashboard’
We reckon that:
- a ‘blank slate’ templates page is a better start
- the example template hurt more than it helped when it comes to
understanding placeholders
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.
Previously, the AJAX update for the dashboard was returning a big blob
of JSON with one key.
This commit splits it up to return:
- one key for each section of the page
- each containing a smaller chunk of HTML rendered from a partial
The jobs page was already working this way (pretty much) but just needed
a little tweaking to get it the same.
Steps to reproduce:
- make a template with a placeholder
- click ‘send yourself a test’
- leave fields blank
- click ‘check’
- see error, click ‘back’
Expected: previous page
Actual: previous page with blue help sidebar
When the URL contains `help=0`, `request.args.get('help')` returns '0'.
Doing `if '0':` is the same as doing any `if <non empty string>:` which
returns `True`.
So we should only display the help when the help query parameter is:
- not missing
- AND a string that isn’t `'0'`
