Steps to reproduce:
- make a template with a placeholder
- click ‘send yourself a test’
- leave fields blank
- click ‘check’
- see error, click ‘back’
Expected: previous page
Actual: previous page with blue help sidebar
When the URL contains `help=0`, `request.args.get('help')` returns '0'.
Doing `if '0':` is the same as doing any `if <non empty string>:` which
returns `True`.
So we should only display the help when the help query parameter is:
- not missing
- AND a string that isn’t `'0'`
While test messages technically have a file and are a job, there’s not
much reason to ever revisit them. So all they end up doing is cluttering
the dashboard and making it harder to find the actual files you’ve
actually uploaded from your computer.
So this commit:
- abstracts the name of test messages into config
- filters out any files whose filename represents a test message
- adds some more thorough tests for the jobs on the dashboard
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.
parts of the initial setup/login stages were throwing 500s if user
not already in process (ie: user directly navigated to url):
* /resend-email-verification
* /text-not-received
* /send-new-code
* verify
> 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
We can filter all notifications by status already. This commit reuses
the same code to filter the notifications for a job by status.
This means that, visually we can show the count on a job the same as
we do for all notifications, which is similar to how we show the counts
on the dashboard, so hopefully it feels like a bit more of a solid
thing.
This also applies to CSV downloads and AJAX updates, which will inherit
any filtering that their parent page has applied.
We can filter notifications on the activity page by state.
This commit adds counts to those filters.
This is mainly so that we can consistently do the same thing on the job
page later on.
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.
registration will allow user to check and modify mobile number.
Registered (active) users will only be able to request resend to their
existing registered number.
If you get linked to a single version of a template, you’re at a dead
end. Let’s add a link to go back up a level to where you can understand
the current version in context.
We have tables listing notifications on:
- the job page
- the ‘activity’ page
Previously that had subtly different information, in a different order.
This commit makes them exactly the same.
- _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`
Downloading a CSV of notifications is very similar to viewing them on
a webpage. So I think it’s sensible to move the assertions about the
CSV download link into the same test, rather than it being it’s own
test.
This means being able to reuse the parametrization introuced in this
commit’s parent.
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
When you edit a template, you’re probably going to do something with
it straight afterwards, eg send yourself a test.
We could make it easy to find the template you’ve just saved by putting
it at the top of the pile. This gets confusing for other reasons (order
of templates will constantly shift about).
So this commit changes the flow to take you to the single page for the
template you’ve just edited.
This commit rearranges the CSV errors (again) to make them geared towards
teaching you how to match placeholders to the column headers.
So the order of errors now is:
1. No phone number/email column
2. Column headers don’t match placeholders
3. Missing or bad data
4. Trial mode
5. Daily limit reached
This depends on:
- [x] https://github.com/alphagov/notifications-utils/pull/39 for 1.
