- _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
While battling the bank holiday traffic on my way home this evening I realised
why looking at the job page was causing lots of 403 errors in the Chrome
console (a spike which was reflected on the Graphite screen).
There is a separate `.json` endpoint for getting updates to a job. This enpoint
did not have the `admin=True` option set in its permissions decorator. So when
viewing a service as a platform admin you could see the page, but not receive
any AJAX-powered updates to it.
_The code for this is quite hacky and light on tests. But I’d really like to get
it in the app for the research tomorrow to see how well the feature works._
This commit changes the tour from being a set of static screens to some help
which guides you through the process of sending your first test message.
The theory behind this is that what users are really struggling with is the
concept of a variable, rather than the relationship between the placeholders and
the column headers. And like learning to program, the best way to learn is by
taking an example and modifying it to your own needs.
This means that when someone adds their first service we set them up an
example email template and an example text message template. Then there is a
guided, three step process where _all_ the user can do is send a test message to
themselves.
Once the message is sent, the user still has the example templates which they
can edit, rather than having to remember what they’re supposed to be doing.
If you’re downloading a bunch of reports from your jobs then it’s useful to be
able to differentiate between them. This commit makes it easy to do so by naming
the file with:
- the name of the template
- when the job was created
We were getting some weirdness like ‘Failed both’.
This commit fixes the problem, and adds some tests for the page headings
to make sure they don’t break again.
Statuses used to be:
- failed
- complaint
- bounce
- sent
- delivered
Now they are:
- sent
- sending
- delivered
This change broke the notifications page on the admin app.
It also made me realise that we should be ignoring ‘sending’ messages in
the history page—it should only show messages we’ve tried to deliver.
The code for this is a bit of a bodge, but it will get things working
again for now.
Means you can see, for example emails that have failed.
Means adding:
- logic to generate links which can have a type parameter, a status
parameter, or both
- a ‘pill’ UI component for seeing which filters you currently have
applied
- some logic to change the page title based on which filters you have
applied
A new permission has been added, view_activity, to resolve this issue.
Another pull request in notifications-admin will be required to update all users with a default permission of view_activity.
The template for viewing a job was not getting all the variables it needed in
order to display an email template. Hadn’t noticed this before, because email
templates require more variables than SMS templates.
This commit fixes that bug.
This is a first go at having the job page update without refreshing.
The approach I’ve taken is to do all the rendering of HTML on the server side,
rather than use a Javascipt templating engine like mustache. This ensures that
we don’t have to maintain two sets of templates.
So the approach is to split the job page into partials. These partials can then:
- be included in the job page to render the whole page
- be rendered indivudually and then returned as a blob of HTML inside a JSON
response
Then I’ve added a Javascript module which looks for areas of the page that should
be reloaded. For each area of the page it will poll a URL and re-render that
section of the page when it gets new HTML. It implements some throttling so that
API calls will never happen more frequently than 0.67 times/second.
Use one page template for each of:
- choosing a message template
- adding recipients
- checking an email message
- looking at a job
This commit consolidates the two templates into one, and adds logic to show
the SMS message pattern or the email message pattern depending on the type of
template.
It also gives email templates a bit more width, because the body and the from
address tend to be quite long.
This commit brings in the `Template` util, added here:
https://github.com/alphagov/notifications-utils/pull/1
It also does a fair bit of tidying up, which I’ve unfortunately squashed into
this one massive commit. The main change is moving 404 handling into the
templates dao, so that every view isn’t littered with `try: … except(HTTPError)`.
It also adds new features, in a prototypy sort of way, which are:
- download a prefilled example CSV
- show all the columns for your template on the 'check' page
This commit:
- adds the template to the jobs page (and puts it at the top of the send SMS
page) so that it consistently appears in the same place throughout the
journey
- put the real data about a job on the jobs page and on the dashboard
From the:
- dashboard
- activity page
This info will be confusing for users at the hack day, because it will say
they’ve already sent messages when they first sign up.
This involved changing the table macro to have a nice ‘no rows’ message.
