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
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.
```
https://www.pivotaltracker.com/story/show/117630691
There is a limit of 50 messages per day in trial mode. Right now, we
don’t tell you this, we just start failing your messages.
This commit adds an error message if you upload a CSV file that has too
many rows in it.
Depending on the size of the uploaded file, Flask will temporarily store
it in different ways. This means that it comes back as a `TempFile` if
the file is roughly <500k and as `BytesIO` if the file is larger.
`TempFile` supports the `.getvalue()` method, but `BytesIO` does not.
Both support the `.read()` method, so this commit changes to use that
instead.
It’s a bit of a weird experience to be taken to the sign in screen when
you click GOV.UK in the header. It’s doubly weird if you take the tour
before creating an account, and at the end of the tour you get prompted
to sign in.
This commit adds some extra logic to take you to the homepage instead,
which I think is more what you’d expect.
> We show the last weeks template usage on the dashboard, which is
> great, but if you're looking for longer term trends, you're out of
> luck...
> So, let's let you see more on a more detailed page (linked from the
> dashboard). Initially this should just show you all templates that you
> have used ever and the count for each. Order same as dashboard, most
> popular first.
https://www.pivotaltracker.com/story/show/117614585
Previous the table of templates on the dashboard was for all time.
This commit uses the `limit_days` parameter of the API endpoint to only
show template usage from the last 7 days, aligning with the big numbers
shown above.
We want to align all our stats to be for the last 7 days.
This means summing up the stats response from the API to make the Big
Number. Previously the big number was counting sent notifications as
successful. This commit changes it to only look at delivered
notifications.
Right now, the API doesn’t have a way of filtering to only show the last
7 days. So for the moment the dashboard will show statistics for all
time.
The upshot of this is that we can link from the dashboard to the
activity page when there are failures.
For users who:
- want to send messages from a template
- want to edit templates
For developers:
- who need to get the ID of a template
This commit mainly cleans up the choose template page so there are less
options, and the options that are there are less wordy.
This means:
- moving ‘send yourself a test’ onto the send messages page, and making
it button
- stripping a lot of stuff out of the ‘send from API’ page, so it’s more
obvious what the template ID is
