We’ve removed the template on the jobs page, so you can no longer see
which template a job is about to be sent with.
This is removing information which might enable you to undo a costly
mistake.
I don’t think we need to bring back the whole template – giving its
name, and a link to it meets the need just as well.
Showing the template on the job page was semi-useful when you couldn’t
see the contents of each individual message. It was still a bit weird
because it just showed the template, never the actual messages that
went out, with the placeholders.
Now that users can click through to see individual messages, and can see
a short preview of the content on each row I think we can safely lose
the template preview on this page.
In tables where we show rows and rows of information we used to give
some meta information about the notification, or at least as much as we
could give in the very limited space available.
This information is now on the notifications page, so the information we
show in these tables should just be whatever helps users identify the
right message. I reckon that this is:
- the content of the message for text messages
- the subject for emails and letters
This also makes these pages consistent with:
- the inbound SMS page
- the way the people’s inboxes work for their text
messsages/Whatsapps/emails
For consistency’s sake this makes the job page work the same way. It may
be slightly less useful here because on the job page every message is
sent from the same template, so will have broadly the same content.
Because manually editing the URL isn’t a great user interface, this
commit adds a search field to do this on the user’s behalf.
For this pass at the story it doesn’t do any validation – the user will
just get no results if they search by something which isn’t a phone
number or email address.
If the user navigates to a different ‘bucket’ of notifications (eg
delivered, failed) then the search term is reset, because they’ve
changed the filter which is at a level above the search term.
> Service teams that use the admin interface often need to know the
> outcome of a message... at the moment they have to page through all
> the results in the activity stream. They should be able to find
> notifications by email address or phone number.
– https://www.pivotaltracker.com/n/projects/1443052
This commit adds an additional query string parameter (`to`) to the URL,
which users can use to filter down the list of notifications.
It:
- takes the status into account
- doesn’t update the counts based on the search term (in reality each
service will only send a handful of notifications to one person in any
7 day period)
In other words the funnel that filters down the notifications looks
like:
> all notifications for service → only failed → only to this phone
> number
before each request, we put the current service on the flask session,
except for with the static folder, cos it's not needed.... except, if
we 404, then we return the 404 template, which checks if you're logged
in or not to display different nav bar items. This was crashing when
current_service wasn't set, so we now set it.
also cleaned up some imports and stuff in test files
The previous, weekly activity breakdown was what we reckoned might be
useful. But now that we have people using the platform it feels like
aggregating a service’s usage by month is:
- matches the timeframe users report on within their organisation
- is consistent with the usage page
And like the usage page this commit also limits the page to only show
one financial year’s worth of data at once (rather than data for all
time).
This commit also makes some changes to the jobs view code so that our
aggregation of failure states is consistent between the dashboard pages
and the jobs pages.
We have a bunch of different styles of handling when function
definitions span multiple lines, which they almost always do with tests.
Here’s why an argument per line, single indent is best:
- cleaner diffs when you change the name of a method (one line change
instead of multiple lines)
- works better on narrow screens, eg Github’s diff view, or with two
terminals side by side on a laptop screen
- works with any editor’s indenting shortcuts, no need for an IDE
Also, trailing comma in the list of arguments is good because adding a
new argument to a method becomes a one line, not two line diff.
We can no longer trust that the content of templates stored in the
database is safe.
Utils now has code to sanitise the content of templates.
This commit:
- updates utils to bring this code in
- modifies some integration tests to make sure everything is working
(there are more extensive unit tests in utils)
If you’re looking back at a job that was scheduled and has now been sent
it’s more useful and consistent to know what time it went out. The time
it was uploaded at is a bit arbitrary once it’s sent.
The only time the uploaded time is relevant is when the job is still
waiting to be sent.
Slightly fiddlier than it sounds because we never want to show
‘uploaded by’ for a job that hasn’t been scheduled because it almost
immediately changes to ‘sent by’. This flickering of the UI is
undesirable.
Friday at 4pm is easier to understand than 14 October at 4pm, especially
when the UI you’ve used to choose this time has talked about days of the
week.
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.
This commit changes the tables of notifications from 3 columns to two
columns. This is so the text has more room, so it doesn’t start
overlapping.
It also makes sure that if the recipient gets really long that it will
be cut off with an ellipsis, rather than overlapping…
I hypothesize that if a notification fails you probably don’t care when
it failed, just that it failed.
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.
The GOV.UK content style guide says:
> - 5:30pm (not 1730hrs)
> - midnight (not 00:00)
> - midday (not 12 noon, noon or 12pm)
This commit changes all times to be 12h not 24h, and adds a special case
for when a time is exactly 12:00am or 12:00pm.
Similar to how we do it on the check page, we should indicate if there
are more results than we can show. No-one’s really complained about the
absence of this, but it can’t hurt.
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.
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.
The previous text didn’t make it clear _what_ you were downloading as a
CSV file, you had to infer it from the context.
And the fact that it’s a CSV file is immaterial, it’s the data you care
about, not the format.
