Splitting the dashboard into multiple sections was confusing, and people
sometimes mistook the headings as labels, especially when a section was
empty. It just wasn’t clear what the hierarchy of the page was.
This commit combines the current and pending broadcasts into one list
on the dashboard. Previous broadcasts have already moved to their own
page.
If you refresh the page on a current broadcast while someone has
cancelled it you’ll see the wrong navigation item selected. This commit
adds redirects to take you to the correct endpoint in these edge cases.
Once a broadcast has been submitted for approval it either lives on the
‘Current alerts’ or ‘Previous alerts’ page, depending on where it is
in its lifecycle.
Therefore when clicking into a broadcast from one of those pages the
same navigation item should remain selected.
Because we select the navigation items based on the request endpoint,
this means we need an endpoint for each navigation page, even if the
content of the pages will be the same in both cases.
This commit adds the two new end points, removes the old, single
endpoint and updates links to point to the new endpoint.
The idea was that this would be a place to document all the design
patterns used in Notify. However it hasn’t been kept up to date, and,
looking at the `git blame`[1] no new patterns have been added for 5
years.
I think it’s better to get rid of it than have to keep maintaining
something which is inaccurate.
1. 64aa0d359c/app/templates/views/styleguide.html
The dashboard for normal services is quite general, because it tells
you a bit about channels, templates and spend.
What is now the dashboard for broadcast services is much more specific,
therefore less like a dashboard. We can reflect this by giving it a more
specific name. This should reduce the amount of navigation surfing
people need to do in order to find the thing they’re looking for.
Previous alerts are much less important than ones that are live or
waiting for approval.
Therefore we can make the dashboard more focused by moving previous
alerts to their own page.
We don't need these anymore as all users will use the `one-off/step`
routes.
This has mostly involved tidying up the tests which are still a little
disorganised and not as good as I'd like but it's a step in the right
direction.
More refactoring is still possible to the routes, it may come in a later
PR if I have time.
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.
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.
We don't want them being able to tour with a template they don't have
folder permissions to see.
Also, when a new user creates a service they will always have full
permissions so this won't affect new services at all, it's just to stop
people 'hacking' the urls to enable them to see templates they maybe
shouldn't see if they knew the template ID
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.
