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.
This commit makes the tests for the `broadcast` service permission more
robust by:
- adding coverage of endpoints that have been created since the test was
first written
- checking that the endpoint also responds to a `post` request with a
`403` (or `405` where it is a `get`-only endpoint)
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.
These tests make sure the sub-categories shown
when a category is selected are right but the
comparison looked for a direct match between the
labels for both types.
This looks for the category label in the
sub-category label instead, ie.
'Today at' in 'Today at 1pm'.
...instead of
'Today at' === 'Today at 1pm', which will always
fail.
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`.
There was a lot of duplicate code here for updating the status and other
properties of a broadcast.
This commit abstracts them into reusable methods. They’re named with an
underscore to suggest that they shouldn’t be used externally.
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.
This was broken because current_service doesn’t update itself after
calling the `update` method of the API. So we thought we were changing
the permissions like this:
```
{'email', 'sms', 'letter'}
{'email', 'sms', 'letter', 'broadcast'}
{'sms', 'letter', 'broadcast'}
{'letter', 'broadcast'}
{'broadcast'}
```
But actually we were doing this:
```
{'email', 'sms', 'letter'}
{'email', 'sms', 'letter', 'broadcast'}
{'sms', 'letter'}
{'email', 'letter'}
{'email', 'sms'}
```
This commit changes the code to update the permissions like this:
```
{'email', 'sms', 'letter'}
{'broadcast'}
```
It does so by adding a new method to the service model which changes all
the permissions in one API call, and updates the tests to mock the
underlying API call, not the method on the model.
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.
Ensures that:
- test name reflects what it now does
- only one parameter per line
- argument order in parameterize matches argument order in function
definition
When a service is switched over to broadcast it has the email, text
message and letter permissions removed. And the links to switch these
settings back on are hidden.
This commit ensures that even if the user manually goes to the URLs for
these pages, they still won’t be able to switch the other channels back
on.
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.
