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.
When you’re dropped straight into the ‘edit template’ page it’s still
a bit confusing what the thing you’re typing is—the mental model isn’t
quite there yet.
I think it will help (rather than redirect to the dashboard) to redirect
to the choose template page. You can then choose to edit the example or
add your own template.
This should help people understand that the example is one of a number
of templates that you create.
The table on this page looked too much like something you were supposed
to interact with. To understand what’s expected of you from this page,
you need to know:
- what you’ve done to make this page happen (you changed some stuff)
- what actions are available now (confirm, back)
The rest of the information is supplemenatary—it helps you make a
descision, but it’s not key to understanding what the decision _is_.
This also matches what we do on the upload file page, where the
non-essential example is under the button.
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
Add descriptions for fields body, template_version, subject for response to POST, update coding example.
Replace single ' with double " in coding examples.
Our boxes are running Python 3.4.3. Travis was set to use 3.5. This is
bad because it means that tests can pass on Travis but then the app can
fail to start.
Python 3.5 introduced the ability to do unpacking before keyword
arguments, eg
```
my_method(**dictionary, foo=bar)
```
This was introduced in https://www.python.org/dev/peps/pep-0448/
This is not valid syntax in Python 3.4, which is what’s running on our
boxes.
This commit changes an instance of this syntax which was introduced in
56d9c29e91
> 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
A long email message needs to be collapsed to only show the first few
lines. The problem is that we were doing this by adding a class with
Javascript, meaning that the email wasn’t being collapsed until the
script in the footer ran.
This caused a jump in the page because the browser was painting the
whole email message, then repainting it once it was collapsed.
This commit takes advantage of the `.js-enabled` class added to the
`<body>` by a script in the `<head>` of GOV.UK template.
This means that the email message is collapsed with CSS before the first
paint of the page, so no jump.
This introduces some complexity in how we determine which emails get the
expander toggle. Because they’re already collapsed we can’t get their
height and work out if they’re long enough to need collapsing.
So we need to take a copy of the message, put it off-screen, expand it,
get its height, then remove it from the DOM. Bit of a faff.
Because of this there’s still a quick flash of the toggle if you see an
email message that’s too short to need collapsing. I think this is the
lesser of two evils—very short email messages will be few and far
between in the real world.
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.
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.
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.
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.
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.
With the change in implementation in the previous commit, any error
(eg server responds with `500`) would cause the page to not be updated
again.
This is better than the previous implementation, whereby the browser
would re-request as fast as it could until it got a successful response.
This commit handles errors by clearing the render queue if the server
returns an error. So:
- Any updates that would have been performed based on this request are
dropped
- Subsequent updates will be attempted as if it was the first load of
the page, ie after a delay of `x` seconds
The `updateContent` module updates a section of the page based on an
AJAX request.
The current implementation will poll every `x` seconds. If the server
takes a long time to respond, this results in a the browser queuing up
requests. If a particular endpoint is slow, this can result in one
client making enough requests to slow down the whole server, to the
point where it gets removed from the loadbalancer, eventually bringing
the whole site down.
This commit rewrites the module so that it queues up the render
operations, not the requests.
There is one queue per endpoint, so for
`http://example.com/endpoint.json`:
1. Queue is empty
```javascript
{
'http://example.com/endpoint.json': []
}
```
2. Inital re-render is put on the queue…
```javascript
{
'http://example.com/endpoint.json': [
function render(){…}
]
}
```
…AJAX request fires
```
GET http://example.com/endpoint.json
```
3. Every `x` seconds, another render operation is put on the queue
```javascript
{
'http://example.com/endpoint.json': [
function render(){…},
function render(){…},
function render(){…}
]
}
```
4. AJAX request returns queue is flushed by executing each queued
render function in sequence
```javascript
render(response); render(response); render(response);
```
```javascript
{
'http://example.com/endpoint.json': []
}
```
5. Repeat
This means that, at most, the AJAX requests will never fire more than
once every `x` seconds, where `x` defaults to `1.5`.
