This commit makes the CSV download use the same language for failure
reasons as the frontend.
It also adds a test around this stuff, which was patchily tested before.
The team page was a bit of a mess:
- invited and active tables didn’t line up
- lots of things were wrapping onto two lines
- the empty fields for when a user didn’t have permissions looked broken
This commit splits each row of the table (not actually a table any more)
onto two lines. First line has the user’s info, second has their
permissions and any associated actions.
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.
We’ve seen people land on this page and expect the message to be on
their phone already.
‘Check and confirm’ sounds a lot like ‘check your phone’, which is
language that we use earlier on when we _have_ sent a message.
Hopefully ‘preview’ is a better indication that it’s not sent yet.
After the tour we should ground users by dropping them on the dashboard.
In the background, we delete the example text message template. This
means that users start from a clean slate when they go to add their own
templates
This also means some wording changes to the tour so it still makes
(some) sense:
- 1, 2 and 3 should refer to the current step, not describe the next
one
- the link should take you to the dashboard
- change from ‘Get started’ to ‘Try this example’ because we’re using
‘Get started on the dashboard’
Since you can’t really send or edit a deleted template we should show
a message telling you that the template has been deleted.
This is important because deleted templates still show up in the
template statistics.
We reckon that:
- a ‘blank slate’ templates page is a better start
- the example template hurt more than it helped when it comes to
understanding placeholders
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.
