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’
Because the placeholder highlighting was defined in pixels it got
slightly out of line when it was used at larger type sizes, eg inside a
heading.
By using `em`s it will scale with the size of the type.
The job is complete when all notifications are delivered or failed.
The report is complete once we have all notifications are in the
database.
This commit changes the meaning of the percentage from the former to the
latter. This is how it was before we removed the aggregate stats for
jobs.
This is just some refactoring.
`defaultdict` is a data structure which won’t raise a `KeyError` if you
try to access a key that doesn’t exist.
By passing `int` as the first argument, trying to access the value of
any key that doesn’t exists will return the value of `int()`, ie `0`
It’s useful to know how many notifications we’ve handed off to our
providers. This is a measure of how complete the processing of the job
is.
This is important, because once the job processing is complete then you
can accurately reconcile the report with the CSV file that you’ve
uploaded.
The mesaure on these pages was too short, making them awkward to read.
Also varies the size of text boxes to make them appropriate to the
expected size of content that they will contain.
