If you have scheduled and then cancelled jobs this would be enough to
show the jobs block on the dashboard (in otherwords it wasn’t filtering
out cancelled jobs). However the contents of the table _were_ filtering
out cancelled jobs, so the table would be empty and look broken.
This commit changes the conditional to operate on the `list` of jobs
with cancelled ones filtered out.
I was using the trial mode page to prototype the time picker as part of
225a61ddd3.
I didn’t clean up properly, and left an errant undefined variable, which
caused the trial mode page to `500`.
This commit:
- removes the errant argument
- adds a test for all the static pages to make sure that they at least
return a `200`
If you schedule a job you might change your mind or circumstances might
change. So you need to be able to cancel it. This commit adds a button
on the job page which hits the `…/cancel` API endpoint for a job.
The information about a job doesn’t make sense if a job is cancelled.
We could change the information to reflect that the job won’t be sent/
wasn’t sent/was cancelled, but there’s nothing you can really do with
this info.
So instead let’s:
- hide cancelled jobs from the dashboard
- hide cancelled jobs from the jobs page
- 404 the page if the user tries to click back enough times to hit the
job page
The way that we collapse column headings so that they don’t take up any
vertical space is by setting their `font-size` to zero. However this
seems to take them out of the flow of the document, so their top border
also disappears. This commit sets the `font-size` to the smallest
non-zero value to avoid this.
The create job endpoint returns the data about the job with a `data:`
wrapper. This commit makes sure that, when the client is trying to
process a job which has just been created, it looks inside the `data`
wrapper.
Features:
- Expose Diff object
Fixes:
- Reverse actions for modifyComment/Text
- Simplify diff on some text only diffs
- Simplify diff on single element removal
The diffDOM Javascript sometimes throws an error if it can’t calculate
a diff between the original content of the page and the updated HTML
delivered via AJAX. The problem seems to be when there’s not one,
consistent top-level element for it to base its calculations on.
This commit:
- makes sure that all AJAX-delivered partials have a wrapping `<div>`
- that this `<div>` has a consistent class name to make it clear why
it’s there
For two reasons:
- it’s extra stuff in tour that users dont yet need to know about
- test messages are hidden from the dashboard, so you’d have no
visibility of when they were sending once you’d scheduled them
If a job is scheduled then we can’t show the notifications yet, and the
progress report will stay at 0%.
In their place we should show what time a job will start.
Later on (when the API is ready) this area of the page should also show
a cancel button.
On the dashboard:
- adds a new ‘in the next 24 hours’ section to the dashboard which lists
upcoming jobs
- tweaks some spacing on the dashboard so that it doesn’t look like too
much of a mess
- don’t show scheduled jobs in the table of normal jobs
On the jobs page:
- don’t show scheduled jobs
The GOV.UK content style guide says:
> - 5:30pm (not 1730hrs)
> - midnight (not 00:00)
> - midday (not 12 noon, noon or 12pm)
This commit changes all times to be 12h not 24h, and adds a special case
for when a time is exactly 12:00am or 12:00pm.
`status` will be deprecated at some point. `job_status` is what gets
set to `scheduled` to show that a job has been scheduled for some time
in the future.
Users need to pick a time in the next 24hrs, or send a file immediately.
Rationale for this is a bit lost in time-before-holiday, but generally:
‘Now’ and ‘later’ as the inital choices makes it really clear what
this feature is about conceptually.
The choice of times is absolute, eg ‘1pm’ not ‘in 3 hours’
