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.
https://github.com/alphagov/gds_metrics_python/blob/master/CHANGELOG.md#021
This will mean that if an exception is thrown in any `before_request`
functions that run before the gds metrics `before_request` function,
then we will no longer throw an uncaught exception.
Note, this could still be the case (and has been seen in production) as
`init_app(application)` in `create_app` in `init.py` can indeed throw
exceptions, for example when it can't find the current service. We could
move our init app for gds metrics further up if we wanted to to further
counter this.
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.
Leaflet seems to be the go-to library for rendering maps these days. It
will be useful for the broadcast work.
This commit add the leaflet Javascript and CSS to our asset pipeline.
The Javascript is already minified so all we need to do is copy it. The
CSS is uncompressed so we put it through the same pipe as our other
stylesheets.
I’m keeping these as separate files because they’re quite heavy (or the
JS is at least – 38kb minified) so I want them to only be loaded on the
pages where they’re used. Most users of Notify will never need to see a
map.
At the moment this won’t look like much, but it will let us do an
end-to-end run of adding a broadcast template.
At the moment all you can do with a broadcast template is edit it, so
there’s no ‘Send’ link on the page.
At the moment the page is the same as for text message templates,
except:
- different H1
- no guidance about personalisation, links, etc (until we decide how
these should work)
For now you won’t be able to really create a broadcast template, because
the API doesn’t support it (the API will respond with a 400). But that’s
OK because no real services have the broadcast permission yet.
This required a bit of refactoring of how we check which template types
a service can use, because there were some hard-coded assumptions about
emails and text messages.
