It’s an irreversible action if you do click it, so it feels like an ‘Are
you sure?’ step is sensible. Follows the same pattern for deleting
templates, etc.
Different emergencies will need broadcasts to last for a variable amount
of time. We give users some control over this by letting them stop a
broadcast early. But we should also let them set a maximum broadcast
time, for:
- when the duration of the danger is known
- when the broadcast has been live long enough to alert everyone who
needs to know about it
This code re-uses the pattern for scheduling jobs, which has some
constraints that are probably OK for now:
- end time is limited to an hour
- longest duration is 3 whole days (eg if you start broadcasting Friday
you have the choice of Saturday, Sunday and all of Monday, up to
midnight)
If a broadcast definitely shouldn’t go out (for example because it has a
spelling mistake or is going to the wrong areas) then we should have a
way of removing it. Once it’s removed no-one else can approve it, and it
isn’t cluttering up the dashboard.
This is a link (because it’s a secondary action) and red (because it’s
destructive, in that it’s throwing away someone’s work).
Since new broadcasts will go into `pending-approval`, we now need a way
of approving them.
This commit adds a button to this page to start (or approve) the
broadcast. This button is wrapped in a bordered box, to emphasise that
it’s something consequential.
We don’t want one person going full yolo and start broadcasting without
any oversight. This commit changes the flow so that the button on the
‘preview’ page puts the broadcast into `pending-approval`, rather than
directly into `broadcasting`.
When we have an approval flow, `pending-approval` will be the state a
broadcast is in between being a draft and broadcasting.
This means it is the earliest stage at which a broadcast can appear on
the dashboard, so this commit adds a new section at the top of the
dashboard to display these broadcasts (since the dashboard is in a
reverse chronological order).
Rather than displaying the scheduled time, the extra information shown
is the person who drafted the broadcast, since I reckon you’ll be coming
to this page because they’ve asked you to approve their broadcast.
Same technique as we use for other pages that update via AJAX.
I’ve split the page up into separate chunks because the DiffDOM library
we use finds it easier to work out what’s changed when there are fewer
elements/a shallower tree.
This commit adds a page to view a single broadcast. This is important
for two reasons:
- users need an audit of what happened when, and who else was involved
in approving or cancelling a broadcast
- we need a place to put actions (approving, cancelling) on a broadcast
so that you can confirm details of the message and the areas before
performing the action
Currently this is a `get` request from the dashboard. Once we have a page
for viewing an individual broadcast it should probably show there
instead and be a `get`/confirm/`post` loop like for deleting a template.
Shows current and previous broadcasts. Does not add a page for viewing
an individual broadcast.
Broadcasts are split into live and previous.
Draft broadcasts are excluded from the dashboard.
This commit removes the code the puts areas into the session and instead
creates and then updates a draft broadcast in the database.
This is so we can avoid session-related bugs, and potentially having a
large session when we start adding personalisation etc.
Once a broadcast is ready to go it is set to `broadcasting` straight
away with no approval. We’ll revisit this as we learn more about how
users might want to manage who can create and approve broadcasts.
The tests are a bit light in terms of checking what’s on the page, but
clicking through the pages is probably good enough for now.
There can be lots of areas in a library, for example local councils. So
when there is, let’s allow people to do the find-as-you-type thing we
support in lots of other places.
These are just so we have some pages to click through for now. They
don’t use real templates, or any of the broadcast stuff from the
database.
But I think it’s useful to get some skeleton pages in first so that we
can see the map etc working in production, then build on that, without
having to do it all in one mega PR.
For that reason there are two short term things I’ve done in this commit
which should be revisited soon:
- no tests for the endpoints
- data about which areas are selected is stored in the session
