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 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
they're currently expecting a RecipientsCSV object - but we won't
always have that available if we're handling a single notification.
So make the partials take generic variables, and then use a jinja with
block to pass in the correct values from either the check csv page or
the check notification page.
Additionally set the notification check page to show errors nicely -
hide the send button if there were problems, and replace the header
rather than creating a job, after entering the placeholders, you now
send a single notification. This means we don't clog up s3 by creating
lots of one line CSV files.
We’ve made a few changes to the tour recently, without changing the
help text on the left hand side of the screen. So the stuff you see on
the right side of the screen doesn’t quite sync up any more.
This commit adds an extra, introductory page that just shows the
template and a next button, which better matches the ‘every message
starts with a template’ help text.
Works similarly to the delete template flow, because it’s a destructive,
one-way action.
Not on the edit template page, because it’s not something you want to be
considering every time you’re editing a template. And we saw that people
couldn’t find the delete button when it was on this page.
Adds a bit more CSS for the `dangerous` banner type, because the content
here is quite complicated. Breaking it into a list helps, but the
spacing didn’t look right, so needed some tweaking.
Can ship independently of the code that shows the redaction, but needs
the API first.
There are a bunch of services that just have one text message template
and one email template.
In this case the template navigation is essentially the same as the
list of templates – a user can just differentiate by looking at the two
templates. Adding the nav would just be noise in this case.
There are lots of services that only send emails, or only send text
messages. For these services, being able to filter the list of templates
but type is pointless – it won’t cut the list down at all.
This commit adds some logic to only show the navigation if the service
has some variety of template types.
