Once you’ve created a broadcast you’re taken back to the dashboard. This
feels too passive, and you might miss that the broadcast still needs
approval.
We should be much more explicit that you now need to find someone to
approve your broadcast. Taking someone directly to the page for a
broadcast lets us give more information about the status of the
broadcast and what the next steps should be.
This is an initial, prototype-quality attempt at introducing some kind
of tour for users new to broadcasting. A lot of the users we’re speaking
to don’t have a good concept of what broadcasting means, which is
causing usability problems down the line.
We did a similar thing in the early days of Notify to explain the
concept of message templates and personalisation.
This should make the pages slightly quicker to load, because Redis will
return the JSON string faster than the API.
The only change that can happen to a broadcast which doesn’t go through
the admin app is a broadcast ending at its scheduled time. So this could
result in a cached broadcast having a status of `broadcasting` when it
had in fact finished. We already account for this here though:
b2b58ec044/app/models/broadcast_message.py (L89-L94)
User permissions were handled by a group of
BooleanFields but introducing the new checkboxes
changed this to just one field that stores its
data in a list.
It was mentioned in a comment that there could be
a situation, when the instances roll, where clients
are using the old fields but POSTing to a server
running the new code.
https://github.com/alphagov/notifications-admin/pull/3535#discussion_r460872903
This introduces tests for that situation.
dnspython had been changed from 1.16.0 to 2.0.0 in a previous commit,
but this was not compatible with eventlet 0.25.2. This bumps eventlet to
a later version, which has the effect of downgrading dnspython again.
These fields used to use govukCheckboxesField and
so stored their data in a list. They were since
migrated to govukCheckboxField, which extends
BooleanField and so keeps its data as a boolean
value.
This now adds validation for invalid characters on the
LetterAddressForm for one off letters. It also adds a validation failed
message for uploaded letters, precompiled letters sent through the API,
and CSV rows with errors.
This is what we do on the uploads page now. It makes it more obvious
why your search term has returned a certain result if you can see most
of the address, not just the first line.
We’re now normalising and storing the whole address in the
`normalised_to` field. Previously we were only storing the first line
of the address.
Enough time should now have passed that the field will have been
populated for all letters in the database.
Thus we can now tell users that it’s not just the first line they can
search by.
We recently introduced a form control that lets user choose when a
broadcast ends.
Based on the most recent research participant, we think:
- there is a specific misunderstanding of what this control does
- there is a general low level of understanding of what a ‘broadcast’
means
People will try to understand what a ‘broadcast’ is by using mental
models they have for other kinds of messaging, for example text
messages.
Other kinds of messaging are one-to-one, i.e. they go from a sender to a
recipient. They are not ongoing in any way.
Emails and texts are sent at a time (and for all practicable purposes
are received at that same time). So, when we present the user with
a form that controls time, they might well assume it controls the time
when the message will be sent.
This is a feature we offer for sending messages using a spreadsheet, and
that’s where we’ve borrowed this pattern from.
We reinforce this assumption with the labelling of the form control. By
front-loading it with the word ‘When’ we are playing to the users
confirmation bias, i.e. they are interpreting the meaning of the control
in a way that confirms their prior beliefs about how messaging works.
So this commit does two things:
- re-labels the form to front-load the word ‘End’ not ‘When’
- adds text to the page explaining when the broadcast will start, so
there’s a chance of overriding that confirmation bias
If we can get users to go through this before sending a broadcast for
real, it could help them learn what a broadcast is, and how it differs
from sending text messages.
When sending a letter we check how many pages it has and this number
then determines how many PNG images we ask template preview for. When
calculating the page count, we were getting the page count for the
template as it comes from the database (so without any placeholders
filled in). But filling in placeholders in a letter may cause the number
of pages to change, which was the cause of the 'Letter does not have a
page x' errors we were seeing from template-preview.
Now, when we calculate the letter page count during sending, we take the
placeholders that have already been filled in into account.
The API now[1] accepts requests on `…/guest-list` as well as
`…/whitelist`. This commit starts using the former, which means:
- the use of ‘whitelist’ is fully gone from the admin app
- the API can stop using it, at least in URLs
1. As of https://github.com/alphagov/notifications-api/pull/2928
The existing macros added data attributes to any
error message displayed which communicated the
error to Google Analytics (if the user had given
consent).
This re-implements that functionality.
Adds the extra text added to each checkbox label.
It's a copy of the text of the link in the same
list item which does add a lot of duplication to
the test data.
This reformats a lot of the test data, stacking it
to separate out the duplicate items.
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 adding filtering to the user permissions
data.
Classes extending BasePermissionsForm have their
user permissions handled by permissions_field
which stores its data in a list. This replaces the
previous approach of having a BooleanField for
each role.
Because permissions_field.data is taken directly
from POST data, it needs extra guarding against
values not present in whatever roles model the
class is based on (ie. broadcast_permissions).
Single checkboxes are distinct because:
- they don't need to be wrapped in a `<fieldset>`
- they are a subclass of BooleanField so their
data is either True or False
Nested checkboxes with a single top-level node
will only have one item in their `items` list.
This is because the other choices are children of
that list item.
This means we need to check the `choices`
attribute, which lists all the checkboxes, to see
if they should be marked as a group (by being
wrapped in a `<fieldset>`) or not.
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.
