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.
This is like the ‘pill’ pattern that we use for filtering lists of
notifications. However it is meant for navigating between discrete
things, not a filtered view of the same list.
This is why is has a gutter between each item, and no selected state.
Turns out we already had a pattern about this on the dashboard, so this
commit also changes the dashboard to use the same code.
Features:
- Expose Diff object
Fixes:
- Reverse actions for modifyComment/Text
- Simplify diff on some text only diffs
- Simplify diff on single element removal
The diffDOM Javascript sometimes throws an error if it can’t calculate
a diff between the original content of the page and the updated HTML
delivered via AJAX. The problem seems to be when there’s not one,
consistent top-level element for it to base its calculations on.
This commit:
- makes sure that all AJAX-delivered partials have a wrapping `<div>`
- that this `<div>` has a consistent class name to make it clear why
it’s there
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
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.
The "you only have permission to view this service" banner sort of
makes sense if you don’t have _any_ permissions, but it doesn’t if you
have permission to create API keys. If you can create API keys you can
do a lot more than just view the service.
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
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.
Since we’re removing the write email/write text message calls to action
from the tour, we should reintroduce them to the dashboard, for users
who are unsure what they should do next.
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.
Previously the structure was
```
dashboard.html
|_ today.html
|_ some random html
|_ a few things split into partials
```
This commit simplifies the structure to just be:
```
dashboard.html
|_ partial
|_ partial
|_ …
```
It was a `<dl>` before which is kinda weird. Especially when the jobs
table was a real `<table>`.
It also means we can give it column headings so that new and invited
users have a better idea of what it is.
> When we have jobs that have over 3% failure rates we should highlight
> those so that peoples attention is drawn to deal with the failure.
>
> They would then go to the job view to see what the details are where
> they could filter by failure, but that's a different story...
>
> This is just about calculating and highlighting those that need their
> attention.
— https://www.pivotaltracker.com/story/show/121206123
This commit:
- calculates the failure rate for each job
- makes jobs with a failure rate of > 3% go red on the dashboard
These numbers don’t look very clickable white-on-black.
Blue is the colour of links, so lets see if they are more clickable in
blue.
The same clicking-a-big-number thing is also happening on the activity
page, so this commit also changes the activity page to look the same.
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.
With sending, delivered and failed all on one line there’s not much
space. When these numbers get relatively big (in the 000s) they can
start mushing into each other.
This commit makes them smaller so that they remain separate.
a9f79bcf07 made all tables have a `fixed`
layout. This causes issues with the spreadsheet-looking tables.
This commit treats tables with half-width first columns as the
exception, not the rule, and makes other tables display as before.
The first columns of our tables are always headings for the
subsequent columns, even though they go horizontally.
HTML has the `<th>` tag, which doesn’t just have to be used for headings
along the top of a table. So this commit changes the first column to be
a `<th>`.
This then allows us to style these elements differently, specifically
making them 50% wide. This makes pages like the dashboard align more
nicely.
- _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
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
If you’re only ever sending one template it’s really useful to be able
to jump straight to that template from the dashboard. So this commit:
- shows the template stats even if there’s only one row
- hides the bar chart if there’s only one row (because it will always be
100%, and won’t be obvious what it is without its siblings)
It’s possible that users will have email and SMS templates with similar
names, and will send them depending on their users’ contact preferences.
So it’s useful to be able to compare how many emails vs SMS you’re
sending, even if the template names are similar.
The dashboard looked a bit table-y. This commit makes four main changes:
- show a bar chart (drawn in CSS) for template usage (only shown if
you’ve used more than one template recently)
- only break down template usage by template name, not template type
(because that’s happening with the big numbers)
- change the style of the ‘show more’ links under each section so that
they are all consistent, and a little less busy (one less keyline)
- remove the ‘recent templates‘ title so that the first two sections of
the page group under ‘in the last 7 days’
Make it clear that this section is about what you’ve used, ie your usage
Click ‘breakdown’ to see how the maths is done, and what time period it
covers.
Takes the number of emails and SMS fragments sent from:
https://github.com/alphagov/notifications-api/pull/273
Using these numbers it’s possible to show:
- how much of your allowance is left
- or how much you have spent
For now the allowance and rates are hard coded.
Only for users that have manage service.
The big numbers on the home page relate directly to the notifications on
the notification page. So let’s link them. With a _hyper_ link.
This commit actually adds two links, one of which is semantically
correct, and one of which is visually correct, ie makes the whole black
area of the box clickable/hoverable.
Requested, delivered and failed are the three states stored in the
notification statistics table. They are not discrete, eg a message can
be counted in delivered and failed.
`requested` is incremented *when a notification is created*, and has no
chance of being incremented twice for the same notification.
The template statistics are incremented *when a notification is created
only*.
Therefore the only way to make the numbers line up is to count:
- messages sent as being `requested`
- failure rate being `failed`/`requested` *not*
`failed`/`failed`+`delivered`
