Two reasons to not hide rejected broadcasts:
- if a broadcast was rejected by mistake then it’s useful to have an
audit of who did that
- it means you can still see old broadcasts without having to leave
in pending-approval, which is dangerous because they might
accidentally be approved
A commit was added:
600e3affc1
In it, it falls back to the string 'Unknown' for actions done by those
not belonging to the service.
This commit changes the behaviour such that if the user is not in the
list of active users for a service, it will go get the user from the DB
(or redis). This should be fine to do as redis will protect us from most
calls as most of these cases are for platform admins.
This will mean we can now see which user platform admin put a service
live rather than seeing 'Unknown'.
This allows MNOs to test delivery to multiple non-adjacent cells without
risk of sending a broadcast on the public network. This will also support
testing of multiple polygon geometries in a single message.
Test polygons are all non-UK (northern Finland).
Signed-off-by: Richard Baker <richard.baker@digital.cabinet-office.gov.uk>
If an area has a `count_of_phones` value of `0` it means we don’t have
data about the population.
This means we can’t do the maths to work out the estimated bleed. So we
should return the default amount of bleed of 1,500m instead, which is
something in between what we’d expect for a built up area and a rural
area.
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.
We don’t vary this between different environments so it doesn’t need to
be in the config.
I was trying to look up what this value was and found it a bit confusing
that it was spread across multiple places.
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']!
Previously each navigation class had a list of endpoint to "exclude",
which was only used in tests to ensure that all endpoints in the app
were covered: either they are present in navigation, or excluded.
However, over time the "exclude" lists have grown long and repetitive,
and maintaining each of them individually adds extra work [1][2]. This
switches to a more DRY approach, where the list of excluded endpoints
is defined once, close to the single point of use in the test.
Note the resulting test is _slightly_ less prescriptive, as it will now
pass if an endpoint exist one in navigation, even if it should also
exist in another. This seems a reasonable compromise.
[1]: https://github.com/alphagov/notifications-admin/pull/3788/files#r572809972
[2]: https://github.com/alphagov/notifications-admin/pull/3794/files#diff-39387df3a9f89b313976957e7b5457be20deab1017b2d895541b142b957f1972
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
🚨 Do not merge until after 1 April 2020 🚨
Once this date has past we no longer need to give any services the
previous allowances, so we can remove them from the codebase to avoid
confusion.
It’s possible we change the allowance structure again, but it might
change in a way that this config-based logic doesn’t account for (what
if we did a per-organisation allowance for example). Having both years’
allowances in the config was a quick fix, not a foundation to build on.
It would have given the wrong answer for the first hour of the 2021
financial year.
This was OK before, because we didn’t need this kind of precision. But
now it could mean someone signing up in the middle of the night getting
the wrong free text message allowance, so we should fix it.
