When we add a new property to the broadcast model, we need to delete any
cached broadcasts from Redis that are missing the new property. So this
adds an option to do this to the cache page in platform admin.
I’ve also tried to make it more obvious what the magic numbers in the
test fixture are doing.
Doing this was helpful to Voiceover users as its
announcement of the label meant the page title
(normally announced onload) wasn't skipped.
This isn't the case with JAWS so, prefixing the
title makes it announce it twice.
JAWS has a lot more users and the title being
announced twice is more confusing than not at all
so this removes it.
with reset password email.
This is so when users reset their password they are still
redirected to pages they were meant to visit.
This change was done specifically so everyone who is meant to see
broadcast tour sees it, but it will improve lives of all users
who wanted to visit a page on Notify but then had to reset
their password in the process.
There is no real reason to have to support both 'one-off' steps and also
'test' steps when sending a one off notification. It's a lot of complex
code, just to now set the one of the placeholders in the session.
We make our code much simpler but no longer using the 'test' routes but
instead adding a new endpoint to set the notification recipient when
sending to yourself before continuing on with the rest of the 'one-off'
flow.
After this is deployed for a day then we can completely remove the
'test' routes and this will help remove a lot of code complexity.
We no longer need the `start_tour` page as this has been replaced with
the new `begin_tour` page.
We also no longer need to handle the `help` argument in the
`send_test_step` or `send_one_off_step` as these no longer are
responsible for the tour and don't need to show the help text.
Worth pointing out, the new tour joins into the send one off flow. When
doing a GET `check_tour_notification`, and submitting the form shown on
this page you are POSTed to `send_notification` with `help=3`. Also for
general sending of one off notifications, the POST to
`send_notification` is done with `help=0` which is a bit of a hack to
make sure that we don't show a back link on the `view_notification` page
for when someone gets there having just sent a one off notification.
This use of `help=0` may be a candidate for a refactor in the future as
it feels like a bit of a hacky way of doing things and is therefore not
as clear to developers what is going on.
Also removes the help argument from the csv routes used here. There is
no reason that we need to ever show help for CSVs and this is leftover
code from when we used to do the tour that way.
The existing behaviour focused the form control
for each popup (radios or textbox) when opened.
This gives no indication the submit button or
cancel link have been added to the page.
These changes:
- make the parent element a region to group all
the new content
- label the region to link it to the button that
opened it
- add a description to the region so users know
how to use it and that all the controls have
been added to the page
On submit of form on this page, will continue to normal sending flow
which can be shared code as there is no longer previous context needed
of where they have come from
Note, we choose to start our urls at step-1 rather than step-0 as this
is consistent when you would enter the first placeholder (excluding the
recipient) for the one off tour.
Also note, we expect a service to allow international sms by default
when it is first created but we keep the check for if the service does
just in case they visit this tour later on.
Suggested by the Digital Accessibility Centre in
their report. Giving these buttons
aria-expanded=false indicates:
- they control a section on the page
- that section is collapsed (and so clicking the
button will open it)
