We have a reckon that live broadcasts don’t feel prominent,
consequential or active enough on the dashboard.
This commit adds an animated component, similar to an ‘on air’ indicator
in a broadcast studio, or a ‘recording’ indicator on a video camera.
This is one option for addressing our reckon. We shouldn’t merge this
until we have a better understanding of the problem from another round
of user research.
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`.
Since we’ll be linking to pending broadcasts from the dashboard, the
page needs to be ready to display them.
Pending broadcasts lack a few bits of information that live or previous
broadcasts have (like the start date for example). So this commit hides
the code that displays those bits of information.
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.
The styling of the empty message seems to conflict with the hard-coded
widths added by the `dashboard-table` class. So we should only add the
`dashboard-table` class when there is content we need to control the
width of.
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.
The api returns letter details split by postage, so international
letters are returned with a postage of `europe` or `rest-of-world` not
`international` and these rows need to be added together when the rate
is the same before they are displayed on the usage page.
To do this, we need to replace the postage of `europe` and
`rest-of-world` with `international`. The data then needs to be sorted
by postage and rate before the letter units for rows which are
international and have the same rate are added together.
No functional changes, but this changes the letter details that are
used for the usage page from a tuple to a named tuple since this makes
it easier to understand.
This conditional comes from before we launched the letters feature.
Since we were only giving the letters permission to teams that we were
inviting, we didn’t want to confuse new users by mentioning letters.
Nowadays all new services will have the letters permission, so this
check is redundant.
The checkboxes need an accessible name that
identifies the folder/template and this needs to
include their full path to avoid duplication.
There's a lot of debate about how to write out
breadcrumb/path syntax so this just puts all the
words together under the assumption that the
folder naming will describe the path (and to
introduce as little extra semantics as possible
to start with).
Moves the link out of the label and increases
the hit-size for the checkbox. The intention is to
reduce the chance of clicking the wrong thing by
accident.
This includes a TODO in the checkboxes component
template code. The item meta needs to be
associated with the checkbox input by use of
`aria-describedby` but this needs changes in
govuk-frontend-jinja to happen.
Includes:
1. changes to make NestedFieldMixin work
with new fields and CSS for nested checkboxes
2. adds custom version of GOVUK checkboxes
component to allow us to:
- add classes to elements currently inaccessible
- wrap the checkboxes in a list
- add child checkboxes to each checkbox (making
tree structures possible through recursion
Change 2. should be pushed upstream to the GOVUK
Design System as a proposal for changes to the
GOVUK Checkboxes component.
Services with the broadcast permission won’t be able to send emails,
text messages or letters. So we should avoid confusion by removing any
reference to these things.
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
Shows the broadcasts with the longest time still to live at the top. At
the moment this will be the same as the newest broadcasts, so we may
want to revisit this sort order when we have broadcasts of variable
duration.
For no-longer-live broadcasts we show the most-recently-finished at the
top, whether it finished naturally or was cancelled.
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.
