This prevents us from giving unrealistically large or small bleed
estimates in case we have areas which are more dense or less dense than
the most/least dense areas we currently have.
Also means we don’t have to treat City of London as a special case.
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
now that we no longer set it since
https://github.com/alphagov/notifications-admin/pull/3841 was merged, we
don't need to remove it either. And we can remove checks that expect it
when cleaning up the session. And the unit tests that make sure we
ignore it if it's in the session.
So long, session['invited_user'] and session['invited_org_user']!
the invited_user objects can be arbitrarily large, and when we put them
in the session we risk going over the session cookie's 4kb size limit.
since https://github.com/alphagov/notifications-admin/pull/3827 was
merged, we store the user id in the session. Now that's been live for a
day or two we can safely stop putting the rich object in the session.
Needed to change a bunch of tests for this to make sure appropriate
mocks were set. Also some tests were accidentally re-using fake_uuid.
Still pop the object when cleaning up sessions. We'll need to remove
that in a future PR.
The `/accounts` page was listing trial mode services twice if a user
belonged to an org. They were shown under both the 'Live services' and
'Trial mode services' sections. After this change, 'Live services' will
show all live services (whether or not they belong to an org) and 'Trial
mode services' will show all trial mode services. If a user belongs to an
org, they will also see the summary of how many services per org at the
top of the page.
A couple of services in tests were renamed for clarity.
We used to upload this to performance platform to show the list of
services and organisations.
There is no longer a performance platform to upload this file to.
The performance page expects all live services to have an organisation.
This should be true on production, but it isn’t always the case in
other environments.
When the organisation name is `None`, the frontend can’t sort the list
of organisations alphabetically and so raises an exception.
first of a two step process to remove invited user objects from the
session. we're removing them because they're of variable size, and with
a lot of folder permissions they can cause the session to exceed the 4kb
cookie size limit and not save properly.
this commit looks at invited org users only.
in this step, start saving the invited org user's id to the
session alongside the session object. Then, if the invited_org_user_id
is present in the next step of the invite flow, fetch the user object
from the API instead of from the session. If it's not present (due to a
session set by an older instance of the admin app), then just use the
old code to get the entire object out of the session.
For invites where the user is small enough to persist to the cookie,
this will still save both the old and the new way, but will always make
an extra check to the API, I think this minor performance hit is totally
fine. For invites where the user is too big to persist, they'll still
fail for now, and will need to wait until the next PR comes along and
stops saving the large invited user object to the session entirely.
This uses the existing endpoint so it matches what’s on the homepage.
It will be more up-to-date than the list of services, but no-one’s going
to be adding things up to check they match exactly.
This matches the existing performance platform page, and I think is a
bit easier to read for high-level numbers where you don’t need to see
that they’re changing second-by-second.
There’s no useful information in the page for the future financial year
because there’s no way for any of the services to have yet used
anything.
Changes this matches the change we made to the service usage page in
https://github.com/alphagov/notifications-admin/pull/3439/files
We’re going to have different allowances next financial year. This means
that when someone adds a service, we’ll need to check which year it is,
so we can give them the right allowance.
This commit changes the config structure so that the current allowances
are explicitly assigned to the 2020/21 financial year.
It freezes the tests to the 2020/21 financial year, so they won’t start
failing automatically when next financial year comes around.
This adds an audit event to the `events` table when the broadcast
permissions for a service (the service mode, channel or provider
restriction) changes.
Sometimes we get a service ID from a support ticket or a Slack
discussion. Rather than having to hack the URL, this PR augments the
‘Find services by name’ page to support service IDs. If a UUID is
entered, it assumes that it’s been given a service ID, and redirects
straight to the dashboard for that service, without showing any search
results (a complete UUID would never match multiple services). If the
UUID is not a service ID, the user will get a 404.
The links in the blue boxes on the job page needed hidden text so that
they work out of context. This changes the text from "10 sending" to "10
sending text messages" (with the message type hidden text).
All services have the `upload_document` permission now, so we don't need
to check for it on the email formatting page. This also deletes a test
which is not needed now.
