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.
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.
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.
Allows checkboxes to be collapsed so they take up
less space in the page. The collapsed state
includes a live summary tracking which of them are
selected.
Includes changes to the JS for collapsible
checkboxes to make it work with the GOVUK
Checkboxes component HTML.
govukCheckboxesField subclasses
SelectMultipleField and overwrites how it renders
HTML to let us use the GOVUK Checkboxes component
while retaining all the functionality of WTForms
fields.
Based on work on github.com/richardjpope/recourse:
https://github.com/richardjpope/recourse/blob/master/recourse/forms.py#L6
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.
This brings it back a bit closer to the page with the map, so the two
feel cohesive, while still making the selected areas look different to
textboxes.
This is borrowed from an earlier prototype, and is meant to be temporary
– something better than just plain text.
Text in generated content isn’t always announced by screen readers, so
we should definitely move away from that once we understand what text
will be shown on the phone and where it comes from.
We’re not going to have an API for sending broadcasts at the moment, so
you don’t need the template ID for anything.
Broadcast also won’t contain personal information, or tokenised links,
etc, so there’s no need to redact them after sending.
Removing this things means the interface is less cluttered.
There are lots of places where we redirect people to the dashboard, for
example after logging in. Rather than add logic to all these places to
check for the broadcast permission, let’s just redirect from the normal
dashboard to the broadcast dashboard.
Other places like the main navigation can still link directly to the
broadcast dashboard, where we do care about speed and not going through
multiple redirect jumps.
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.
Gives them some colours, borders and stuff to make them visually
consistent with the rest of Notify.
The idea is the tags and polygons have a similar affordances (i.e.
border thickness, colour) to visually link them and imply that they are
two representations of the same thing.
So you can check you’ve chosen the right areas, and to give you a clear
idea of where the boundaries of an area are.
The Javascript and CSS for the map is only loaded on this page because
it adds quite a few kb, and we don’t want to be sending assets to the
majority of our users who will never see them.
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
Services doing broadcasts wont:
- incur costs, so don’t need to see the usage page
- be sending anything by uploading, so don’t need to see the uploads
page
- (for now) be sending anything using the API, so don’t need to see the
API integration page
Brings in:
- re-usable `SerialisedModel`
- speed improvements to processing CSVs against email templates
I chose not to rename `JSONModel` or `ModelList` to keep the diff nice
and small.
Similar to how we can restrict routes to only users with a given
permission, this new decorator lets us restrict routes to services that
have a given permission.
Having this is a decorator is cleaner than putting if statements inside
the endpoint code.
