darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-05-01 14:41:25 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
2cfd22b20ceab2afaec79dee7396579661bfd5a9
notifications-admin/app/models/broadcast_message.py

258 lines
7.9 KiB
Python
Raw Normal View History

Refactor coordinate processing into Polygons class We have a bunch of stuff for doing lat/long transformation in the `BroadcastMessage` class. This is not a good separation of concerns, now that we have a separate class for dealing with polygons and coordinates.
2020-08-25 16:55:09 +01:00
import itertools
Remove choice of ‘End time’ from broadcast journey Since we added the end time picker: - we have discovered that broadcasts can’t be longer than 24h - we have observed that most users confuse picking the end time for scheduling the message, or don’t understand exactly what it means for the broadcast to ‘end’ - we’ve developed the concept of ‘training mode’, which you should be going through before sending a real broadcast We also think that, for most scenarios, you won’t necessarily know when a broadcast should end at the time of starting it because the cause of the danger is not within your control. So giving you control of the end time before the broadcast has even been approved is a confusing distraction. Having to pick a time at all also makes the whole process feel more planned and less immediate. Whereas in reality all the phones in the area will be getting the message in seconds. It’s only people coming into the area later to whom the ‘ongoing’ aspect of the broadcast applies. The best place to explain what’s happening with the phones is at the approval stage and once you’ve sent your first (training mode) broadcast. It’s easier to explain what’s happened if it’s in direct response to something you’ve just done. Later on we should add some kind of email reminder after 12 hours to make sure you still want the broadcast live, again after 18 hours, etc. We could let you schedule an end time once the broadcast is live, but don’t think there’s a strong need. Knowing enough that you want to cancel is one thing, but knowing enough to want to cancel but wanting to wait a bit… nah.
2020-08-18 16:36:40 +01:00
from datetime import datetime, timedelta
Make the broadcast flow talk to the API 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.
2020-07-09 10:33:50 +01:00
Replace polygons module with the one from utils We moved it in https://github.com/alphagov/notifications-utils/pull/818/files
2021-01-25 13:49:23 +00:00
from notifications_utils.polygons import Polygons
Make the broadcast flow talk to the API 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.
2020-07-09 10:33:50 +01:00
from notifications_utils.template import BroadcastPreviewTemplate
from orderedset import OrderedSet
Don’t let users self-approve broadcasts At the moment they will get a ‘technical difficulties’ error if they try. We probably want to do something around letting people self-approve broadcasts in trial mode, but for now just telling them they can’t is a better experience than ‘technical difficulties’ (and will probably be close to what they should see on a live service as well).
2020-08-05 16:01:21 +01:00
from werkzeug.utils import cached_property
Make the broadcast flow talk to the API 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.
2020-07-09 10:33:50 +01:00
Move broadcast model code into an explicit module Previously this was hidden away in an anonymous __init__.py file. I did think about splitting the models into individual files, like we do with the top-level models for the app. Since the models are only imported in one place - i.e. are all used together - it didn't seem worth the hassle, so I've kept them in one file.
2021-06-10 15:05:38 +01:00
from app.broadcast_areas.models import (
CustomBroadcastAreas,
broadcast_area_libraries,
)
Extract formatters into their own module We have lots of functions for converting various types of data into strings to be displayed to the user somewhere. This commit collects all these functions into their own module, rather than having them cluttering up `app/__init__.py` or buried amongst various other things that have ended up in `app/utils.py`.
2021-01-06 12:12:01 +00:00
from app.formatters import round_to_significant_figures
Add broadcasts to the dashboard 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.
2020-07-09 15:48:56 +01:00
from app.models import JSONModel, ModelList
Add a page to view a single broadcast 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
2020-07-10 14:06:00 +01:00
from app.models.user import User
Make the broadcast flow talk to the API 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.
2020-07-09 10:33:50 +01:00
from app.notify_client.broadcast_message_api_client import (
broadcast_message_api_client,
)
Give estimates of the number of phones in a broadcast area We need to give people a better feel for the consequences of broadcasting an alert. We’ve seen in research that some users will assume it is subscription based, or opt-in, rather than going to every phone in the area. I reckon that the most effective way to communicate this is to put some numbers next to the areas, to give people an idea of how many people will get alerted. We can estimate how many phones are in an area by: - taking the population of all electoral wards in that area - multiplying it by the percentage of people who own an internet connected phone[1] The Office for National Statistics publish both these datasets. The number of people who own an intenet connected phone varies a lot by age. Since the population data for each ward is broken down by age we can factor this in. Simplified, the calculation looks like this: - take the _Abbey_ ward of _Barking and Dagenham_ - in this ward there are 26 people aged 80 - 40% of people over 65 have an internet-connected phone - therefore 10 of these 80-year-olds would be likely to receive a broadcast - (repeat for all other ages) These numbers won’t be exact, but should be enough to give people a feel for the severity of what they’re about to do. We can see if they acheive this aim in user research. 1. This is a proxy for the number of people who are likely to have a 4G capable phone, because only 4G capable phones will be receiving broadcasts to begin with
2020-09-09 13:29:45 +01:00
Make the broadcast flow talk to the API 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.
2020-07-09 10:33:50 +01:00
class BroadcastMessage(JSONModel):
ALLOWED_PROPERTIES = {
'id',
'service_id',
'template_id',
Recognise that broadcast messages include content The content attribute needs to be added to the model so we can use it later.
2020-10-08 14:06:33 +01:00
'content',
Make the broadcast flow talk to the API 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.
2020-07-09 10:33:50 +01:00
'service_id',
'created_by',
'personalisation',
'starts_at',
'finishes_at',
'created_at',
'approved_at',
'cancelled_at',
'updated_at',
'created_by_id',
'approved_by_id',
'cancelled_by_id',
}
libraries = broadcast_area_libraries
Implement sorting 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.
2020-07-10 09:26:47 +01:00
def __lt__(self, other):
Sort broadcasts by start time For emails and text messages we sort by the time the user (or API) sent them. This makes sense for broadcasts too, since most users will receive the alert within seconds of it being broadcast. For alerts that haven’t started yet we can sort by `updated_at`, which is when the user preparing the broadcast submitted it for approval.
2020-10-16 09:02:35 +01:00
if self.starts_at and other.starts_at:
return self.starts_at < other.starts_at
if self.starts_at and not other.starts_at:
return True
if not self.starts_at and other.starts_at:
return False
Show broadcasts created by the API Broadcasts created by the API are different in that: - they aren’t created by any user, so don’t have a `created_by_id` - they are created instantly, not in steps, so don’t have an `updated_at` time This commit alters the views to account for when these pieces of information aren’t present.
2021-01-27 11:24:22 +00:00
if self.updated_at and not other.updated_at:
return self.updated_at < other.created_at
if not self.updated_at and other.updated_at:
return self.created_at < other.updated_at
Allow broadcasts which have no created_at to be compared This adds to the `__le__` method on the `BroadcastMessage` class to allow two BroadcastMessages with no `updated_at` to be compared. Previously, the method expected at least one message to have `updated_at` set, but this is not necessarily the case.
2021-02-09 09:32:07 +00:00
if not self.updated_at and not other.updated_at:
return self.created_at < other.created_at
Sort broadcasts by start time For emails and text messages we sort by the time the user (or API) sent them. This makes sense for broadcasts too, since most users will receive the alert within seconds of it being broadcast. For alerts that haven’t started yet we can sort by `updated_at`, which is when the user preparing the broadcast submitted it for approval.
2020-10-16 09:02:35 +01:00
return self.updated_at < other.updated_at
Implement sorting 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.
2020-07-10 09:26:47 +01:00
Make the broadcast flow talk to the API 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.
2020-07-09 10:33:50 +01:00
@classmethod
def create(cls, *, service_id, template_id):
return cls(broadcast_message_api_client.create_broadcast_message(
service_id=service_id,
template_id=template_id,
Add flow for composing an alert without a template We think that in some cases alerts will be composed in the moment, and therefore making people first create a template is: - not a good use of their time - adding some conceptual complexity which they don’t need This commit makes it possible to type some words and have them go straight into the `content` field in the database. In the future we might want to progressively enhance the radio buttons so they show on the same page (like we do with the grey buttons on the templates page).
2020-11-20 15:42:52 +00:00
content=None,
reference=None,
))
@classmethod
def create_from_content(cls, *, service_id, content, reference):
return cls(broadcast_message_api_client.create_broadcast_message(
service_id=service_id,
template_id=None,
content=content,
reference=reference,
Make the broadcast flow talk to the API 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.
2020-07-09 10:33:50 +01:00
))
@classmethod
def from_id(cls, broadcast_message_id, *, service_id):
return cls(broadcast_message_api_client.get_broadcast_message(
service_id=service_id,
broadcast_message_id=broadcast_message_id,
))
@property
def areas(self):
Check that all areas are in the library We should assume to start with that areas come either from the library or from the JSON, and not a combination of the two.
2021-01-27 14:32:35 +00:00
library_areas = self.get_areas(areas=self._dict['areas'])
if library_areas:
if len(library_areas) != len(self._dict['areas']):
raise RuntimeError(
f'BroadcastMessage has {len(self._dict["areas"])} areas '
f'but {len(library_areas)} found in the library'
)
return library_areas
return CustomBroadcastAreas(
Display areas that aren’t in the library
2021-01-26 10:14:04 +00:00
areas=self._dict['areas'],
polygons=self._dict['simple_polygons'],
)
Make the broadcast flow talk to the API 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.
2020-07-09 10:33:50 +01:00
Suggest previously-used areas when adding new area If you’re adding another area to your broadcast it’s likely to be close to one of the areas you’ve already added. But we make you start by choosing a library, then you have to find the local authority again from the long list. This is clunky, and it interrupts the task the user is trying to complete. We thought about redirecting you somewhere deep into the hierarchy, perhaps by sending you to either: - the parent of the last area you’d chosen - the common ancestor of all the areas you’d chosen This approach would however mean you’d need a way to navigate back up the hierarchy if we’d dropped you in the wrong place. And we don’t have a pattern for that at the moment. So instead this commit adds some ‘shortcuts’ to the chose library page, giving you a choice of all the parents of the areas you’ve currently selected. In most cases this will be one (unitary authority) or two (county and district) choices, but it will scale to adding areas from multiple different authorities. It does mean an extra click compared to the redirect approach, but this is still fewer, easier clicks compared to now. This meant a couple of under-the-hood changes: - making `BroadcastArea`s hashable so it’s possible to do `set([BroadcastArea(…), BroadcastArea(…), BroadcastArea(…)])` - making `BroadcastArea`s aware of which library they live in, so we can link to the correct _Choose area_ page
2020-09-21 18:55:46 +01:00
@property
def parent_areas(self):
return sorted(set(self._parent_areas_iterator))
@property
def _parent_areas_iterator(self):
for area in self.areas:
for parent in area.parents:
yield parent
Make simplification of polygons more sophisticated Simplifying polygons means reducing the number of points used to render them. This commit implements simplification such that, for any given input polygons, the combined point count of the simplified polygons is less than 100. When simplifying the polygons we are trying to get the smallest number of points while meeting these two rules: 1. No part of the area the user has chosen can be cut off 2. The area of the simplified polygon should be as small as possible This commit introduces two techniques we weren’t using before: 1. Dilating and eroding the area to fill in concave details of the shape, like inlets and harbours[1] 2. Making the simplification threshold proportionate to the perimeter of all polygons, so bigger and crinklier polygons get more simplification applied It also shows the estimated bleed as a separate polygon. This lets us make it bigger (so it’s more closer the the approximate bleed) without having to send a bigger area to the CBC and compounding the amount of actual bleed. 1. Inspired by this blog post about ‘removing the crinkley bits’ from Vancouver Island: http://blog.cleverelephant.ca/2010/11/removing-complexities.html
2020-08-24 12:51:23 +01:00
@cached_property
Make the broadcast flow talk to the API 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.
2020-07-09 10:33:50 +01:00
def polygons(self):
Make simplification of polygons more sophisticated Simplifying polygons means reducing the number of points used to render them. This commit implements simplification such that, for any given input polygons, the combined point count of the simplified polygons is less than 100. When simplifying the polygons we are trying to get the smallest number of points while meeting these two rules: 1. No part of the area the user has chosen can be cut off 2. The area of the simplified polygon should be as small as possible This commit introduces two techniques we weren’t using before: 1. Dilating and eroding the area to fill in concave details of the shape, like inlets and harbours[1] 2. Making the simplification threshold proportionate to the perimeter of all polygons, so bigger and crinklier polygons get more simplification applied It also shows the estimated bleed as a separate polygon. This lets us make it bigger (so it’s more closer the the approximate bleed) without having to send a bigger area to the CBC and compounding the amount of actual bleed. 1. Inspired by this blog post about ‘removing the crinkley bits’ from Vancouver Island: http://blog.cleverelephant.ca/2010/11/removing-complexities.html
2020-08-24 12:51:23 +01:00
return Polygons(
Refactor coordinate processing into Polygons class We have a bunch of stuff for doing lat/long transformation in the `BroadcastMessage` class. This is not a good separation of concerns, now that we have a separate class for dealing with polygons and coordinates.
2020-08-25 16:55:09 +01:00
list(itertools.chain(*(
area.polygons for area in self.areas
)))
Show how a broadcast will overspill selected area Broadcasting is not a precise technology, because: - cell towers are directional - their range varies depending on whether they are 2, 3, 4, or 5G (the higher the bandwidth the shorter the range) - in urban areas the towers are more densely packed, so a phone is likely to have a greater choice of tower to connect to, and will favour a closer one (which has a stronger signal) - topography and even weather can affect the range of a tower So it’s good for us to visually indicate that the broadcast is not as precise as the boundaries of the area, because it gives the person sending the message an indication of how the technology works. At the same time we have a restriction on the number of polygons we think and area can have, so we’ve done some work to make versions of polygons which are simplified and buffered (see https://github.com/alphagov/notifications-utils/pull/769 for context). Serendipitously, the simplified and buffered polygons are larger and smoother than the detailed polygons we’ve got from the GeoJSON files. So they naturally give the impression of covering an area which is wider and less precise. So this commit takes those simple polygons and uses them to render the blue fill. This makes the blue fill extend outside the black stroke, which is still using the detailed polygons direct from the GeoJSON.
2020-08-06 13:38:15 +01:00
)
Store simplifed polygons in the SQLite database This commit does two things: - uses our new polygon-simplifying library to process the polygons before storing them, rather than processing them in real time - stores only the polygons in the database, rather than the whole GeoJSON feature, because we don’t need any of the other information about the feature
2020-08-24 14:43:28 +01:00
@cached_property
def simple_polygons(self):
Send simple polygons to API along with areas When creating broadcast message, or updating it. We want to send simple polygons to API so we can later relay them to the broadcast provider. Test that update broadcast message sends polygons correctly
2020-09-02 14:54:00 +01:00
return self.get_simple_polygons(areas=self.areas)
Store simplifed polygons in the SQLite database This commit does two things: - uses our new polygon-simplifying library to process the polygons before storing them, rather than processing them in real time - stores only the polygons in the database, rather than the whole GeoJSON feature, because we don’t need any of the other information about the feature
2020-08-24 14:43:28 +01:00
Vary bleed amount based on population density There are basically two kinds of 4G masts: Frequency | Range | Bandwidth ----------|-------------|---------------------------------- 800MHz | Long (500m) | Low (can handle a bit of traffic) 1800Mhz | Short (5km) | High (can handle lots of traffic) The 1800Mhz masts are better in terms of how much traffic they can handle and how fast a connection they provide. But because they have quite short range, it’s only economical to install them in very built up areas†. In more rural areas the 800MHz masts are better because they cover a wider area, and have enough bandwidth for the lower population density. The net effect of this is that cell broadcasts in rural areas are likely to bleed further, because the masts they are being broadcast from are less precise. We can use population density as a proxy for how likely it is to be covered by 1800Mhz masts, and therefore how much bleed we should expect. So this commit varies the amount of bleed shown based on the population density. I came up with the formula based on 3 fixed points: - The most remote areas (for example the Scottish Highlands) should have the highest average bleed, estimated at 5km - An town, like Crewe, should have about the same bleed as we were estimating before (1.5km) – Pete D thinks this is about right based on his knowledge of the area around his office in Crewe - The most built up areas, like London boroughs, could have as little as 500m of bleed Based on these three figures I came up with the following formula, which roughly gives the right bleed distance (`b`) for each of their population densities (`d`): ``` b = 5900 - (log10(d) × 1_250) ``` Plotted on a curve it looks like this: This is based on averages – remember that the UI shows where is _likely_ to receive the alert, based on bleed, not where it’s _possible_ to receive the alert. Here’s what it looks like on the map: --- †There are some additional subtleties which make this not strictly true: - The 800Mhz masts are also used in built up areas to fill in the gaps between the areas covered by the 1800Mhz masts - Switching between masts is inefficient, so if you’re moving fast through a built up area (for example on a train) your phone will only use the 800MHz masts so that you have to handoff from one mast to another less often
2021-03-12 09:17:42 +00:00
@cached_property
def simple_polygons_with_bleed(self):
polygons = Polygons(
list(itertools.chain(*(
area.simple_polygons_with_bleed for area in self.areas
)))
)
# If we’ve added multiple areas then we need to re-simplify the
# combined shapes to keep the point count down
return polygons.smooth.simplify if len(self.areas) > 1 else polygons
Display broadcasts without a template At the moment the admin app expects all broadcasts to have a template, and expects the content of the alert to come from the template. This commit makes it so those pages can still get a `Template` instance, but populated with content straight from the `content` field in the database.
2021-01-15 15:11:43 +00:00
@property
def reference(self):
if self.template_id:
return self._dict['template_name']
return self._dict['reference']
Make the broadcast flow talk to the API 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.
2020-07-09 10:33:50 +01:00
@property
def template(self):
Display broadcasts without a template At the moment the admin app expects all broadcasts to have a template, and expects the content of the alert to come from the template. This commit makes it so those pages can still get a `Template` instance, but populated with content straight from the `content` field in the database.
2021-01-15 15:11:43 +00:00
return BroadcastPreviewTemplate({
'template_type': BroadcastPreviewTemplate.template_type,
'name': self.reference,
'content': self.content,
})
Make the broadcast flow talk to the API 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.
2020-07-09 10:33:50 +01:00
Add broadcasts to the dashboard 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.
2020-07-09 15:48:56 +01:00
@property
def status(self):
if (
self._dict['status']
and self._dict['status'] == 'broadcasting'
and self.finishes_at < datetime.utcnow().isoformat()
):
return 'completed'
return self._dict['status']
Don’t let users self-approve broadcasts At the moment they will get a ‘technical difficulties’ error if they try. We probably want to do something around letting people self-approve broadcasts in trial mode, but for now just telling them they can’t is a better experience than ‘technical difficulties’ (and will probably be close to what they should see on a live service as well).
2020-08-05 16:01:21 +01:00
@cached_property
Add a page to view a single broadcast 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
2020-07-10 14:06:00 +01:00
def created_by(self):
Show broadcasts created by the API Broadcasts created by the API are different in that: - they aren’t created by any user, so don’t have a `created_by_id` - they are created instantly, not in steps, so don’t have an `updated_at` time This commit alters the views to account for when these pieces of information aren’t present.
2021-01-27 11:24:22 +00:00
return User.from_id(self.created_by_id) if self.created_by_id else None
Add a page to view a single broadcast 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
2020-07-10 14:06:00 +01:00
Don’t let users self-approve broadcasts At the moment they will get a ‘technical difficulties’ error if they try. We probably want to do something around letting people self-approve broadcasts in trial mode, but for now just telling them they can’t is a better experience than ‘technical difficulties’ (and will probably be close to what they should see on a live service as well).
2020-08-05 16:01:21 +01:00
@cached_property
Add a page to view a single broadcast 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
2020-07-10 14:06:00 +01:00
def approved_by(self):
Make alert page work for rejected broadcasts The code for this page was making assumptions about properties which aren’t present on rejected broadcasts. This commit accounts for those properties and presents the relevant elements on the page.
2021-04-08 13:34:29 +01:00
return User.from_id(self.approved_by_id) if self.approved_by_id else None
Add a page to view a single broadcast 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
2020-07-10 14:06:00 +01:00
Don’t let users self-approve broadcasts At the moment they will get a ‘technical difficulties’ error if they try. We probably want to do something around letting people self-approve broadcasts in trial mode, but for now just telling them they can’t is a better experience than ‘technical difficulties’ (and will probably be close to what they should see on a live service as well).
2020-08-05 16:01:21 +01:00
@cached_property
Add a page to view a single broadcast 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
2020-07-10 14:06:00 +01:00
def cancelled_by(self):
return User.from_id(self.cancelled_by_id)
Give estimates of the number of phones in a broadcast area We need to give people a better feel for the consequences of broadcasting an alert. We’ve seen in research that some users will assume it is subscription based, or opt-in, rather than going to every phone in the area. I reckon that the most effective way to communicate this is to put some numbers next to the areas, to give people an idea of how many people will get alerted. We can estimate how many phones are in an area by: - taking the population of all electoral wards in that area - multiplying it by the percentage of people who own an internet connected phone[1] The Office for National Statistics publish both these datasets. The number of people who own an intenet connected phone varies a lot by age. Since the population data for each ward is broken down by age we can factor this in. Simplified, the calculation looks like this: - take the _Abbey_ ward of _Barking and Dagenham_ - in this ward there are 26 people aged 80 - 40% of people over 65 have an internet-connected phone - therefore 10 of these 80-year-olds would be likely to receive a broadcast - (repeat for all other ages) These numbers won’t be exact, but should be enough to give people a feel for the severity of what they’re about to do. We can see if they acheive this aim in user research. 1. This is a proxy for the number of people who are likely to have a 4G capable phone, because only 4G capable phones will be receiving broadcasts to begin with
2020-09-09 13:29:45 +01:00
@property
def count_of_phones(self):
return round_to_significant_figures(
Handle areas with missing data At the moment there are some areas which have: - a `count_of_phones` value of `None` - no sub-areas This is wrong, but until we fix the data the phone counting code needs to handle this. This commit: - adds the `or 0` in the right place (where it will catch these areas with missing data) - adds a test which checks these areas, and compares them to other kinds of areas
2020-09-17 11:00:17 +01:00
sum(area.count_of_phones for area in self.areas),
Make estimated phone count clearer We’ve had some feedback from user research that difference between ‘will get alert’ and ‘likely to get alert’ is not clear, and it’s hard to tell if the latter is inclusive of the former. This leads people to question the validity of these numbers, which is important, because an the estimate should give you some idea of the impact of what you’re about to do. This commit reformats the number as a range, for example 1,000 to 2,000 phones. If the range is small, eg 40,000,000 to 40,800,000 then this suggests a false level of accuracy. So instead we just give one number and say it’s an estimate, eg ‘40,000,000 phones estimated’
2020-09-24 15:52:18 +01:00
1
Give estimates of the number of phones in a broadcast area We need to give people a better feel for the consequences of broadcasting an alert. We’ve seen in research that some users will assume it is subscription based, or opt-in, rather than going to every phone in the area. I reckon that the most effective way to communicate this is to put some numbers next to the areas, to give people an idea of how many people will get alerted. We can estimate how many phones are in an area by: - taking the population of all electoral wards in that area - multiplying it by the percentage of people who own an internet connected phone[1] The Office for National Statistics publish both these datasets. The number of people who own an intenet connected phone varies a lot by age. Since the population data for each ward is broken down by age we can factor this in. Simplified, the calculation looks like this: - take the _Abbey_ ward of _Barking and Dagenham_ - in this ward there are 26 people aged 80 - 40% of people over 65 have an internet-connected phone - therefore 10 of these 80-year-olds would be likely to receive a broadcast - (repeat for all other ages) These numbers won’t be exact, but should be enough to give people a feel for the severity of what they’re about to do. We can see if they acheive this aim in user research. 1. This is a proxy for the number of people who are likely to have a 4G capable phone, because only 4G capable phones will be receiving broadcasts to begin with
2020-09-09 13:29:45 +01:00
)
@property
def count_of_phones_likely(self):
area_estimate = self.simple_polygons.estimated_area
Vary bleed amount based on population density There are basically two kinds of 4G masts: Frequency | Range | Bandwidth ----------|-------------|---------------------------------- 800MHz | Long (500m) | Low (can handle a bit of traffic) 1800Mhz | Short (5km) | High (can handle lots of traffic) The 1800Mhz masts are better in terms of how much traffic they can handle and how fast a connection they provide. But because they have quite short range, it’s only economical to install them in very built up areas†. In more rural areas the 800MHz masts are better because they cover a wider area, and have enough bandwidth for the lower population density. The net effect of this is that cell broadcasts in rural areas are likely to bleed further, because the masts they are being broadcast from are less precise. We can use population density as a proxy for how likely it is to be covered by 1800Mhz masts, and therefore how much bleed we should expect. So this commit varies the amount of bleed shown based on the population density. I came up with the formula based on 3 fixed points: - The most remote areas (for example the Scottish Highlands) should have the highest average bleed, estimated at 5km - An town, like Crewe, should have about the same bleed as we were estimating before (1.5km) – Pete D thinks this is about right based on his knowledge of the area around his office in Crewe - The most built up areas, like London boroughs, could have as little as 500m of bleed Based on these three figures I came up with the following formula, which roughly gives the right bleed distance (`b`) for each of their population densities (`d`): ``` b = 5900 - (log10(d) × 1_250) ``` Plotted on a curve it looks like this: This is based on averages – remember that the UI shows where is _likely_ to receive the alert, based on bleed, not where it’s _possible_ to receive the alert. Here’s what it looks like on the map: --- †There are some additional subtleties which make this not strictly true: - The 800Mhz masts are also used in built up areas to fill in the gaps between the areas covered by the 1800Mhz masts - Switching between masts is inefficient, so if you’re moving fast through a built up area (for example on a train) your phone will only use the 800MHz masts so that you have to handoff from one mast to another less often
2021-03-12 09:17:42 +00:00
bleed_area_estimate = self.simple_polygons_with_bleed.estimated_area - area_estimate
Give estimates of the number of phones in a broadcast area We need to give people a better feel for the consequences of broadcasting an alert. We’ve seen in research that some users will assume it is subscription based, or opt-in, rather than going to every phone in the area. I reckon that the most effective way to communicate this is to put some numbers next to the areas, to give people an idea of how many people will get alerted. We can estimate how many phones are in an area by: - taking the population of all electoral wards in that area - multiplying it by the percentage of people who own an internet connected phone[1] The Office for National Statistics publish both these datasets. The number of people who own an intenet connected phone varies a lot by age. Since the population data for each ward is broken down by age we can factor this in. Simplified, the calculation looks like this: - take the _Abbey_ ward of _Barking and Dagenham_ - in this ward there are 26 people aged 80 - 40% of people over 65 have an internet-connected phone - therefore 10 of these 80-year-olds would be likely to receive a broadcast - (repeat for all other ages) These numbers won’t be exact, but should be enough to give people a feel for the severity of what they’re about to do. We can see if they acheive this aim in user research. 1. This is a proxy for the number of people who are likely to have a 4G capable phone, because only 4G capable phones will be receiving broadcasts to begin with
2020-09-09 13:29:45 +01:00
return round_to_significant_figures(
Make estimated phone count clearer We’ve had some feedback from user research that difference between ‘will get alert’ and ‘likely to get alert’ is not clear, and it’s hard to tell if the latter is inclusive of the former. This leads people to question the validity of these numbers, which is important, because an the estimate should give you some idea of the impact of what you’re about to do. This commit reformats the number as a range, for example 1,000 to 2,000 phones. If the range is small, eg 40,000,000 to 40,800,000 then this suggests a false level of accuracy. So instead we just give one number and say it’s an estimate, eg ‘40,000,000 phones estimated’
2020-09-24 15:52:18 +01:00
self.count_of_phones + (self.count_of_phones * bleed_area_estimate / area_estimate),
Give estimates of the number of phones in a broadcast area We need to give people a better feel for the consequences of broadcasting an alert. We’ve seen in research that some users will assume it is subscription based, or opt-in, rather than going to every phone in the area. I reckon that the most effective way to communicate this is to put some numbers next to the areas, to give people an idea of how many people will get alerted. We can estimate how many phones are in an area by: - taking the population of all electoral wards in that area - multiplying it by the percentage of people who own an internet connected phone[1] The Office for National Statistics publish both these datasets. The number of people who own an intenet connected phone varies a lot by age. Since the population data for each ward is broken down by age we can factor this in. Simplified, the calculation looks like this: - take the _Abbey_ ward of _Barking and Dagenham_ - in this ward there are 26 people aged 80 - 40% of people over 65 have an internet-connected phone - therefore 10 of these 80-year-olds would be likely to receive a broadcast - (repeat for all other ages) These numbers won’t be exact, but should be enough to give people a feel for the severity of what they’re about to do. We can see if they acheive this aim in user research. 1. This is a proxy for the number of people who are likely to have a 4G capable phone, because only 4G capable phones will be receiving broadcasts to begin with
2020-09-09 13:29:45 +01:00
1
)
Send simple polygons to API along with areas When creating broadcast message, or updating it. We want to send simple polygons to API so we can later relay them to the broadcast provider. Test that update broadcast message sends polygons correctly
2020-09-02 14:54:00 +01:00
def get_areas(self, areas):
return broadcast_area_libraries.get_areas(
*areas
)
def get_simple_polygons(self, areas):
polygons = Polygons(
list(itertools.chain(*(
area.simple_polygons for area in areas
)))
)
# If we’ve added multiple areas then we need to re-simplify the
# combined shapes to keep the point count down
return polygons.smooth.simplify if len(areas) > 1 else polygons
Make the broadcast flow talk to the API 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.
2020-07-09 10:33:50 +01:00
def add_areas(self, *new_areas):
Send simple polygons to API along with areas When creating broadcast message, or updating it. We want to send simple polygons to API so we can later relay them to the broadcast provider. Test that update broadcast message sends polygons correctly
2020-09-02 14:54:00 +01:00
areas = list(OrderedSet(
Refactor broadcast message model 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.
2020-07-17 08:07:42 +01:00
self._dict['areas'] + list(new_areas)
Send simple polygons to API along with areas When creating broadcast message, or updating it. We want to send simple polygons to API so we can later relay them to the broadcast provider. Test that update broadcast message sends polygons correctly
2020-09-02 14:54:00 +01:00
))
simple_polygons = self.get_simple_polygons(areas=self.get_areas(areas=areas))
self._update(areas=areas, simple_polygons=simple_polygons.as_coordinate_pairs_lat_long)
Make the broadcast flow talk to the API 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.
2020-07-09 10:33:50 +01:00
def remove_area(self, area_to_remove):
Send simple polygons to API along with areas When creating broadcast message, or updating it. We want to send simple polygons to API so we can later relay them to the broadcast provider. Test that update broadcast message sends polygons correctly
2020-09-02 14:54:00 +01:00
areas = [
Refactor broadcast message model 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.
2020-07-17 08:07:42 +01:00
area for area in self._dict['areas']
if area != area_to_remove
Send simple polygons to API along with areas When creating broadcast message, or updating it. We want to send simple polygons to API so we can later relay them to the broadcast provider. Test that update broadcast message sends polygons correctly
2020-09-02 14:54:00 +01:00
]
simple_polygons = self.get_simple_polygons(areas=self.get_areas(areas=areas))
self._update(areas=areas, simple_polygons=simple_polygons.as_coordinate_pairs_lat_long)
Refactor broadcast message model 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.
2020-07-17 08:07:42 +01:00
def _set_status_to(self, status):
broadcast_message_api_client.update_broadcast_message_status(
status,
Make the broadcast flow talk to the API 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.
2020-07-09 10:33:50 +01:00
broadcast_message_id=self.id,
service_id=self.service_id,
)
Refactor broadcast message model 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.
2020-07-17 08:07:42 +01:00
def _update(self, **kwargs):
Make the broadcast flow talk to the API 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.
2020-07-09 10:33:50 +01:00
broadcast_message_api_client.update_broadcast_message(
broadcast_message_id=self.id,
service_id=self.service_id,
Refactor broadcast message model 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.
2020-07-17 08:07:42 +01:00
data=kwargs,
Make the broadcast flow talk to the API 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.
2020-07-09 10:33:50 +01:00
)
Refactor broadcast message model 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.
2020-07-17 08:07:42 +01:00
Remove choice of ‘End time’ from broadcast journey Since we added the end time picker: - we have discovered that broadcasts can’t be longer than 24h - we have observed that most users confuse picking the end time for scheduling the message, or don’t understand exactly what it means for the broadcast to ‘end’ - we’ve developed the concept of ‘training mode’, which you should be going through before sending a real broadcast We also think that, for most scenarios, you won’t necessarily know when a broadcast should end at the time of starting it because the cause of the danger is not within your control. So giving you control of the end time before the broadcast has even been approved is a confusing distraction. Having to pick a time at all also makes the whole process feel more planned and less immediate. Whereas in reality all the phones in the area will be getting the message in seconds. It’s only people coming into the area later to whom the ‘ongoing’ aspect of the broadcast applies. The best place to explain what’s happening with the phones is at the approval stage and once you’ve sent your first (training mode) broadcast. It’s easier to explain what’s happened if it’s in direct response to something you’ve just done. Later on we should add some kind of email reminder after 12 hours to make sure you still want the broadcast live, again after 18 hours, etc. We could let you schedule an end time once the broadcast is live, but don’t think there’s a strong need. Knowing enough that you want to cancel is one thing, but knowing enough to want to cancel but wanting to wait a bit… nah.
2020-08-18 16:36:40 +01:00
def request_approval(self):
Don’t start broadcasts immediately 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`.
2020-07-17 08:07:43 +01:00
self._set_status_to('pending-approval')
Add broadcasts to the dashboard 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.
2020-07-09 15:48:56 +01:00
Add button to approve broadcast 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.
2020-07-17 08:07:44 +01:00
def approve_broadcast(self):
self._update(
starts_at=datetime.utcnow().isoformat(),
Remove choice of ‘End time’ from broadcast journey Since we added the end time picker: - we have discovered that broadcasts can’t be longer than 24h - we have observed that most users confuse picking the end time for scheduling the message, or don’t understand exactly what it means for the broadcast to ‘end’ - we’ve developed the concept of ‘training mode’, which you should be going through before sending a real broadcast We also think that, for most scenarios, you won’t necessarily know when a broadcast should end at the time of starting it because the cause of the danger is not within your control. So giving you control of the end time before the broadcast has even been approved is a confusing distraction. Having to pick a time at all also makes the whole process feel more planned and less immediate. Whereas in reality all the phones in the area will be getting the message in seconds. It’s only people coming into the area later to whom the ‘ongoing’ aspect of the broadcast applies. The best place to explain what’s happening with the phones is at the approval stage and once you’ve sent your first (training mode) broadcast. It’s easier to explain what’s happened if it’s in direct response to something you’ve just done. Later on we should add some kind of email reminder after 12 hours to make sure you still want the broadcast live, again after 18 hours, etc. We could let you schedule an end time once the broadcast is live, but don’t think there’s a strong need. Knowing enough that you want to cancel is one thing, but knowing enough to want to cancel but wanting to wait a bit… nah.
2020-08-18 16:36:40 +01:00
finishes_at=(
Reduce default broadcast expiry time to 4 hours We don’t think we need to broadcast longer than this to validate that the system is working.
2021-02-12 15:49:16 +00:00
datetime.utcnow() + timedelta(hours=4, minutes=0)
Remove choice of ‘End time’ from broadcast journey Since we added the end time picker: - we have discovered that broadcasts can’t be longer than 24h - we have observed that most users confuse picking the end time for scheduling the message, or don’t understand exactly what it means for the broadcast to ‘end’ - we’ve developed the concept of ‘training mode’, which you should be going through before sending a real broadcast We also think that, for most scenarios, you won’t necessarily know when a broadcast should end at the time of starting it because the cause of the danger is not within your control. So giving you control of the end time before the broadcast has even been approved is a confusing distraction. Having to pick a time at all also makes the whole process feel more planned and less immediate. Whereas in reality all the phones in the area will be getting the message in seconds. It’s only people coming into the area later to whom the ‘ongoing’ aspect of the broadcast applies. The best place to explain what’s happening with the phones is at the approval stage and once you’ve sent your first (training mode) broadcast. It’s easier to explain what’s happened if it’s in direct response to something you’ve just done. Later on we should add some kind of email reminder after 12 hours to make sure you still want the broadcast live, again after 18 hours, etc. We could let you schedule an end time once the broadcast is live, but don’t think there’s a strong need. Knowing enough that you want to cancel is one thing, but knowing enough to want to cancel but wanting to wait a bit… nah.
2020-08-18 16:36:40 +01:00
).isoformat(),
Add button to approve broadcast 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.
2020-07-17 08:07:44 +01:00
)
self._set_status_to('broadcasting')
Add a link to reject a broadcast 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).
2020-07-17 08:07:44 +01:00
def reject_broadcast(self):
self._set_status_to('rejected')
Allow broadcasts to be 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.
2020-07-10 09:16:36 +01:00
def cancel_broadcast(self):
Refactor broadcast message model 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.
2020-07-17 08:07:42 +01:00
self._set_status_to('cancelled')
Allow broadcasts to be 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.
2020-07-10 09:16:36 +01:00
Add broadcasts to the dashboard 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.
2020-07-09 15:48:56 +01:00
class BroadcastMessages(ModelList):
model = BroadcastMessage
client_method = broadcast_message_api_client.get_broadcast_messages
def with_status(self, *statuses):
return [
broadcast for broadcast in self if broadcast.status in statuses
]
Reference in New Issue Copy Permalink