Bug was happening because:
```python
bool(list())
>>> False
```
```python
bool((item for item in list()))
>>> True
```
i.e. generator expressions cast to boolean are `True`, even if they’re
empty – Python doesn’t evaluate them.
This was causing the functional tests to fail because it was taking too
long for any table rows to appear on the page.
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.
completely mimicks the job status page, and as such, all the code and
templates have been taken from the job page. This page performs
exactly the same as the job page for now
* total, sending, delivered, failed blue boxes (though they'll just
read 0/1 for now.
* download report button (same as with job download, except without job
or row number in file)
* removed references to scheduled
* kept references to help (aka tour/tutorial) as that'll eventually
change over from a job to a one-off too
See parent commit for the reason we’re doing this.
Currently our AJAX requests only work as `GET` requests. So this commit
does a bit of work to make them work as `POST` requests. This is
optional behaviour, and will only happen when the element in the page
that should be updated with AJAX has the `data-form` attribute set. It
will take the form that has the corresponding `id`, serialise it, and
use that data as the body of the post request. If not form is specified
it will not do the serialisation, and submit as a `GET` request as
before.
Phone numbers and email addresses are showing up in URLs where we let
users search for sent notifications by phone number or email address.
`GET` requests put the form data as a query string in the URL. This is
problematic when people are searching by a recipient’s phone number or
email address, because the URL may show up:
- in our server logs
- in our analytics
- in the user’s browser history
This is bad because these are all places where we don’t want
people’s personal information. It’s not too bad when this is happening
a handful of times. But it would be bad if we kept aggregating this
information because it would allow us to track users across services.
So, while it’s not especially RESTful, it’s better for the search form
to submit as a `POST` request. This way the phone number or email
address goes in the body of the request and does not show up in the URL.
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
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.
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.
