When I split up the error messages on the check CSV page into multiple
templates, I also reduced the repetition of wrapping `<div>`s and macro
calls by moving them up outside the conditional blocks (see
8e947f315d).
Unfortunately I didn’t make the same adjustments for the one-off flow,
which meant that errors on these pages lost their styling. This commit
re-adds the styling for these error messages.
The reason to indent the first column heading is so that the number 1
lines up with the numbers of subsequent rows.
This only happens when the subsequent rows are indented because of the
red bars. This is only when there are row errors, not when there are
more general errors.
There was a lot of repetetive wrapping code being repeated for every
conditional block in these files. Let’s wrap it around the whole
conditional bit once instead.
If you have errors in your file then there’s stuff you’re not going to
see on the page. So this doesn’t need to be in the Jinja templates that
are only used when there are errors.
Basically the conditional stuff is moving up to the level above these
templates.
The status won’t ever change from sending for letters. For now at least.
And even when we do come up with more useful statuses I’m not convinced
it’s useful to expose them to our admin users.
A more useful piece of information to show is when we think the letter
will be delivered.
There’s no immediate feedback with letter jobs, unlike email or text
messages jobs where you see the numbers starting to tick over straight
away.
We need to reassure the user that the thing they asked us to do (send
letters) is underway. ‘Printing’ feels like the natural first state of
the letter-making process. So this commit adds a banner to tell the
user that printing is the thing that’s happening.
The sending/failed/delivered thing:
- doesn’t map to the actual states of letters
- doesn’t respond quickly enough to give you feedback that something is
happening (because "sending" doesn’t even go to "probably delivered"
for a few days)
This commit replaces these 4 boxes with some more useful information:
- one number – how many letters were in the job in total
- when we estimate that the letters will be delivered
The status for each letter in a job will be the same for every single
letter (at least until we start dealing with returns).
It’s redundant to show this information over and over again. This commit
removes it.
The idea is if you decide your problem isn’t such an emergency after
all, we direct you to the form where you can report it as such. This
link wasn’t working because it didn’t understand `False` to mean ‘not
severe’. Only ‘no’ means not severe.
The result was that users got sent in a bit of a convoluted loop
where they were asked again if their problem was an emergency or not.
Testing this by making sure that both:
- the URL in the link is what we expected
- when visited it gives the page title we expect
Because even if we had had the first test only, it wouldn’t have caught
this bug.
If sending SMS is disabled for a service, it should not be possible to
add or modify SMS templates. If a user tries to do this, they should see
a different page with a link to go back. The same thing should happen
with email templates.
Platform admins can now disable sending sms for a service. If sending
sms is disabled, this will also hide all the other sms options in the
Settings table.
Platform admins can now disable sending of emails for a service. If
sending emails is disabled, this will also hide the option to change the
Email reply to address.
This message is meant to indicate that generating the report is still in
progress. Saying 100% contradicts this because 100% sounds like
‘complete’.
Reason this is happening is because rounding 99.5 to 0 decimal places
gives you 100.
So let’s make sure it never gets above 99.0
