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.
If they API returns no statistics for a given time period we should
assume that this is equivalent to 0. This means that the template can
always rely on the dictionary having the same keys.
We saw lots of people in the lab clicking activity hoping for…
something. But it’s not really where you go to do a thing, so they
weren’t finding what they were looking for.
Since you can now get to the activity from the dashboard, let’s remove
the link in the nav, to make thing less ambiguous.
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.
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.
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`
The dashboard should only talk about notifications that are *successful* or
*failed*. It should not count notifications that are still queued.
This will stop:
- a situation like ‘0 emails, 14.1% failed’
- the big numbers and the template statistics numbers not adding up to
the same total
Currently, when we update a section of the page with AJAX we replace the
entire HTML of the section with the new HTML. This causes problems:
- if you’re trying to interact with that section of the page, eg by
inpecting it, clicking or hovering an element
- (probably) for screenreaders trying to navigate a page which is
changing more than is necessary
This commit replaces the call to `.html()` with a pretty clever library
called diffDOM[1]. DiffDOM works by taking a diff of the old element and
the new element, then doing a patch update, ie only modifying the parts
that have changed.
This is similar in concept to React’s virtual DOM, while still allowing
us to render all markup from one set of templates on the server-side.
1. https://github.com/fiduswriter/diffDOM
This commit:
- moves things around a bit on the request to go live page
- sticks a textbox in there
So when someone click the big green button, we will get a support ticket
that looks something like:
```
From Test User <test@user.gov.uk> on behalf of Test Service
(6ce466d0-fd6a-11e5-82f5-e0accb9d11a6)
---
We’ll send about 1000 text messages in the first month, and then 10,000
text messages per month after that. Usage of our service is about 50%
higher in March, at the end of the tax year.
```
