darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-09-03 11:18:45 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
b32cd7c351eee0b2ec9271b88d3a7d28f044dc5b
notifications-admin/tests/app/main/views/test_broadcast.py

2768 lines
83 KiB
Python
Raw Normal View History

Make the broadcast dashboard update via AJAX Same technique as we use for other pages that update via AJAX. I’ve split the page up into separate chunks because the DiffDOM library we use finds it easier to work out what’s changed when there are fewer elements/a shallower tree.
2020-07-14 13:39:29 +01:00
import json
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
import uuid
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
from collections import namedtuple
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
from functools import partial
Make the broadcast dashboard update via AJAX Same technique as we use for other pages that update via AJAX. I’ve split the page up into separate chunks because the DiffDOM library we use finds it easier to work out what’s changed when there are fewer elements/a shallower tree.
2020-07-14 13:39:29 +01:00
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
import pytest
from flask import url_for
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 freezegun import freeze_time
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
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 tests import broadcast_message_json, sample_uuid, user_json
Estimate number of phones in an arbitrary polygon We want to know how many phones are in a user-supplied polygon, so we can show the impact of a broadcast, in the same way that we do when users pick areas from our library. We already know how many phones are in each electoral ward. But there are challenges with an arbitrary polygon: - where it does overlap a ward, the overlap could be partial - it could overlap more than one ward - finding out which wards it overlaps by brute force (looping through all the wards and seeing which ones intersect with our polygon) would be way to slow to do in real time Instead we can use a data structure called an R-tree[1] to build an index which provides a much, much faster way of looking up which polygons overlap another. We can build this tree in advance and save it somewhere, which means there’s a lot of computation we don’t need to do in real time. The R-tree returns a set of objects (ward IDs) which we can go and look up in our library of electoral wards. These wards will be the ones that might have some overlap with our custom polygon. Once we have this small set of wards which might overlap our ward, we can look at the size of the area of overlap (relative to the size of the whole ward) and multiply that by the known count of phones in that ward to get an approximation of the count of phones in the overlap area. Summing these approximations give an estimate for the whole area of the custom polygon. 1. https://en.wikipedia.org/wiki/R-tree
2021-03-18 23:02:32 +00:00
from tests.app.broadcast_areas.custom_polygons import BRISTOL, SKYE
Allow users with new broadcast permissions access to routes Added two new permissions - `create_broadcasts` and `approve_broadcasts`. These new permissions get added to the `has_permissions` decorator of the broadcast routes to allow the routes to be accessed with either the old permissions on the new ones while we switch over. We were using the `send_messages` permission for the broadcast routes. By having two new permissions we can allow a more granular control of these routes.
2021-06-17 18:03:58 +01:00
from tests.conftest import (
SERVICE_ONE_ID,
create_active_user_approve_broadcasts_permissions,
create_active_user_create_broadcasts_permissions,
Use new permissions for the button on the broadcast dashboard The broadcast dashboards contain a button to create a new broadcast. This adds the new `create_broadcasts` permission as one of the permissions needed to see the button.
2021-06-28 08:33:27 +01:00
create_active_user_view_permissions,
create_platform_admin_user,
Allow users with new broadcast permissions access to routes Added two new permissions - `create_broadcasts` and `approve_broadcasts`. These new permissions get added to the `has_permissions` decorator of the broadcast routes to allow the routes to be accessed with either the old permissions on the new ones while we switch over. We were using the `send_messages` permission for the broadcast routes. By having two new permissions we can allow a more granular control of these routes.
2021-06-17 18:03:58 +01:00
normalize_spaces,
)
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +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
sample_uuid = sample_uuid()
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
Update tests for service permission This commit makes the tests for the `broadcast` service permission more robust by: - adding coverage of endpoints that have been created since the test was first written - checking that the endpoint also responds to a `post` request with a `403` (or `405` where it is a `get`-only endpoint)
2020-07-20 09:27:46 +01:00
@pytest.mark.parametrize('endpoint, extra_args, expected_get_status, expected_post_status', (
(
'.broadcast_dashboard', {},
403, 405,
),
(
'.broadcast_dashboard_updates', {},
403, 405,
),
Make a separate page for previous alerts Previous alerts are much less important than ones that are live or waiting for approval. Therefore we can make the dashboard more focused by moving previous alerts to their own page.
2020-10-13 11:40:20 +01:00
(
'.broadcast_dashboard_previous', {},
403, 405,
),
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
(
'.new_broadcast', {},
403, 403,
),
(
'.write_new_broadcast', {},
403, 403,
),
Update tests for service permission This commit makes the tests for the `broadcast` service permission more robust by: - adding coverage of endpoints that have been created since the test was first written - checking that the endpoint also responds to a `post` request with a `403` (or `405` where it is a `get`-only endpoint)
2020-07-20 09:27:46 +01:00
(
'.broadcast',
{'template_id': sample_uuid},
403, 405,
),
(
'.preview_broadcast_areas', {'broadcast_message_id': sample_uuid},
403, 405,
),
(
'.choose_broadcast_library', {'broadcast_message_id': sample_uuid},
403, 405,
),
(
'.choose_broadcast_area', {'broadcast_message_id': sample_uuid, 'library_slug': 'countries'},
403, 403,
),
(
broadcast-areas: use area ids in tests Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>
2020-08-10 13:19:16 +01:00
'.remove_broadcast_area', {'broadcast_message_id': sample_uuid, 'area_slug': 'countries-E92000001'},
Update tests for service permission This commit makes the tests for the `broadcast` service permission more robust by: - adding coverage of endpoints that have been created since the test was first written - checking that the endpoint also responds to a `post` request with a `403` (or `405` where it is a `get`-only endpoint)
2020-07-20 09:27:46 +01:00
403, 405,
),
(
'.preview_broadcast_message', {'broadcast_message_id': sample_uuid},
403, 403,
),
(
Ensure correct selected nav item on broadcast page Once a broadcast has been submitted for approval it either lives on the ‘Current alerts’ or ‘Previous alerts’ page, depending on where it is in its lifecycle. Therefore when clicking into a broadcast from one of those pages the same navigation item should remain selected. Because we select the navigation items based on the request endpoint, this means we need an endpoint for each navigation page, even if the content of the pages will be the same in both cases. This commit adds the two new end points, removes the old, single endpoint and updates links to point to the new endpoint.
2020-10-15 13:15:22 +01:00
'.view_current_broadcast', {'broadcast_message_id': sample_uuid},
Update tests for service permission This commit makes the tests for the `broadcast` service permission more robust by: - adding coverage of endpoints that have been created since the test was first written - checking that the endpoint also responds to a `post` request with a `403` (or `405` where it is a `get`-only endpoint)
2020-07-20 09:27:46 +01:00
403, 403,
),
Ensure correct selected nav item on broadcast page Once a broadcast has been submitted for approval it either lives on the ‘Current alerts’ or ‘Previous alerts’ page, depending on where it is in its lifecycle. Therefore when clicking into a broadcast from one of those pages the same navigation item should remain selected. Because we select the navigation items based on the request endpoint, this means we need an endpoint for each navigation page, even if the content of the pages will be the same in both cases. This commit adds the two new end points, removes the old, single endpoint and updates links to point to the new endpoint.
2020-10-15 13:15:22 +01:00
(
'.view_previous_broadcast', {'broadcast_message_id': sample_uuid},
403, 405,
),
Update tests for service permission This commit makes the tests for the `broadcast` service permission more robust by: - adding coverage of endpoints that have been created since the test was first written - checking that the endpoint also responds to a `post` request with a `403` (or `405` where it is a `get`-only endpoint)
2020-07-20 09:27:46 +01:00
(
'.cancel_broadcast_message', {'broadcast_message_id': sample_uuid},
403, 403,
),
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
))
def test_broadcast_pages_403_without_permission(
client_request,
endpoint,
extra_args,
Update tests for service permission This commit makes the tests for the `broadcast` service permission more robust by: - adding coverage of endpoints that have been created since the test was first written - checking that the endpoint also responds to a `post` request with a `403` (or `405` where it is a `get`-only endpoint)
2020-07-20 09:27:46 +01:00
expected_get_status,
expected_post_status,
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
):
client_request.get(
endpoint,
service_id=SERVICE_ONE_ID,
Update tests for service permission This commit makes the tests for the `broadcast` service permission more robust by: - adding coverage of endpoints that have been created since the test was first written - checking that the endpoint also responds to a `post` request with a `403` (or `405` where it is a `get`-only endpoint)
2020-07-20 09:27:46 +01:00
_expected_status=expected_get_status,
**extra_args
)
client_request.post(
endpoint,
service_id=SERVICE_ONE_ID,
_expected_status=expected_post_status,
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
**extra_args
)
Allow platform admins to cancel broadcasts. Do not allow platform admins to: - create broadcasts - approve broadcasts - reject broadcasts that is, unless they have a send_messages permission for a given service. This is so platform admins have the minimum permissions necessary to cancel a broadcast that might have been sent out accidentally.
2021-04-06 15:08:47 +01:00
@pytest.mark.parametrize('user_is_platform_admin', [True, False])
Add tests to check permission-restricted broadcast pages Some pages should only be shown to users who have permission to send or approve broadcasts. This commit adds a test to ensure that this is true, and that we don’t accidentally regress the checks for this permission.
2020-08-10 12:26:33 +01:00
@pytest.mark.parametrize('endpoint, extra_args, expected_get_status, expected_post_status', (
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
(
'.new_broadcast', {},
403, 403,
),
(
'.write_new_broadcast', {},
403, 403,
),
Add tests to check permission-restricted broadcast pages Some pages should only be shown to users who have permission to send or approve broadcasts. This commit adds a test to ensure that this is true, and that we don’t accidentally regress the checks for this permission.
2020-08-10 12:26:33 +01:00
(
'.broadcast',
{'template_id': sample_uuid},
403, 405,
),
(
'.preview_broadcast_areas', {'broadcast_message_id': sample_uuid},
403, 405,
),
(
'.choose_broadcast_library', {'broadcast_message_id': sample_uuid},
403, 405,
),
(
'.choose_broadcast_area', {'broadcast_message_id': sample_uuid, 'library_slug': 'countries'},
403, 403,
),
(
'.remove_broadcast_area', {'broadcast_message_id': sample_uuid, 'area_slug': 'england'},
403, 405,
),
(
'.preview_broadcast_message', {'broadcast_message_id': sample_uuid},
403, 403,
),
))
def test_broadcast_pages_403_for_user_without_permission(
client_request,
service_one,
active_user_view_permissions,
Allow platform admins to cancel broadcasts. Do not allow platform admins to: - create broadcasts - approve broadcasts - reject broadcasts that is, unless they have a send_messages permission for a given service. This is so platform admins have the minimum permissions necessary to cancel a broadcast that might have been sent out accidentally.
2021-04-06 15:08:47 +01:00
platform_admin_user_no_service_permissions,
Add tests to check permission-restricted broadcast pages Some pages should only be shown to users who have permission to send or approve broadcasts. This commit adds a test to ensure that this is true, and that we don’t accidentally regress the checks for this permission.
2020-08-10 12:26:33 +01:00
endpoint,
extra_args,
expected_get_status,
expected_post_status,
Allow platform admins to cancel broadcasts. Do not allow platform admins to: - create broadcasts - approve broadcasts - reject broadcasts that is, unless they have a send_messages permission for a given service. This is so platform admins have the minimum permissions necessary to cancel a broadcast that might have been sent out accidentally.
2021-04-06 15:08:47 +01:00
user_is_platform_admin
Add tests to check permission-restricted broadcast pages Some pages should only be shown to users who have permission to send or approve broadcasts. This commit adds a test to ensure that this is true, and that we don’t accidentally regress the checks for this permission.
2020-08-10 12:26:33 +01:00
):
Allow platform admins to cancel broadcasts. Do not allow platform admins to: - create broadcasts - approve broadcasts - reject broadcasts that is, unless they have a send_messages permission for a given service. This is so platform admins have the minimum permissions necessary to cancel a broadcast that might have been sent out accidentally.
2021-04-06 15:08:47 +01:00
"""
Test that user without permission cannot accept broadcast Also fix incorrect docstring.
2021-04-20 17:18:33 +01:00
Checks that users without permissions, including admin users, cannot create or edit broadcasts.
Allow platform admins to cancel broadcasts. Do not allow platform admins to: - create broadcasts - approve broadcasts - reject broadcasts that is, unless they have a send_messages permission for a given service. This is so platform admins have the minimum permissions necessary to cancel a broadcast that might have been sent out accidentally.
2021-04-06 15:08:47 +01:00
"""
Add tests to check permission-restricted broadcast pages Some pages should only be shown to users who have permission to send or approve broadcasts. This commit adds a test to ensure that this is true, and that we don’t accidentally regress the checks for this permission.
2020-08-10 12:26:33 +01:00
service_one['permissions'] += ['broadcast']
Allow platform admins to cancel broadcasts. Do not allow platform admins to: - create broadcasts - approve broadcasts - reject broadcasts that is, unless they have a send_messages permission for a given service. This is so platform admins have the minimum permissions necessary to cancel a broadcast that might have been sent out accidentally.
2021-04-06 15:08:47 +01:00
if user_is_platform_admin:
client_request.login(platform_admin_user_no_service_permissions)
else:
client_request.login(active_user_view_permissions)
Add tests to check permission-restricted broadcast pages Some pages should only be shown to users who have permission to send or approve broadcasts. This commit adds a test to ensure that this is true, and that we don’t accidentally regress the checks for this permission.
2020-08-10 12:26:33 +01:00
client_request.get(
endpoint,
service_id=SERVICE_ONE_ID,
_expected_status=expected_get_status,
**extra_args
)
client_request.post(
endpoint,
service_id=SERVICE_ONE_ID,
_expected_status=expected_post_status,
**extra_args
)
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
@pytest.mark.parametrize('user', [
create_active_user_view_permissions(),
create_platform_admin_user(),
create_active_user_create_broadcasts_permissions(),
])
Test that user without permission cannot accept broadcast Also fix incorrect docstring.
2021-04-20 17:18:33 +01:00
def test_user_cannot_accept_broadcast_without_permission(
client_request,
service_one,
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
user,
Test that user without permission cannot accept broadcast Also fix incorrect docstring.
2021-04-20 17:18:33 +01:00
):
service_one['permissions'] += ['broadcast']
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
client_request.login(user)
Test that user without permission cannot accept broadcast Also fix incorrect docstring.
2021-04-20 17:18:33 +01:00
client_request.post(
'.approve_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=sample_uuid,
_expected_status=403,
)
Test that user without permission cannot reject broadcast
2021-04-20 17:24:26 +01:00
@pytest.mark.parametrize('user_is_platform_admin', [True, False])
def test_user_cannot_reject_broadcast_without_permission(
client_request,
service_one,
active_user_view_permissions,
platform_admin_user_no_service_permissions,
user_is_platform_admin
):
service_one['permissions'] += ['broadcast']
if user_is_platform_admin:
client_request.login(platform_admin_user_no_service_permissions)
else:
client_request.login(active_user_view_permissions)
client_request.get(
'.reject_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=sample_uuid,
_expected_status=403,
)
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
def test_user_cannot_cancel_broadcast_without_permission(
Allow platform admins to cancel broadcasts. Do not allow platform admins to: - create broadcasts - approve broadcasts - reject broadcasts that is, unless they have a send_messages permission for a given service. This is so platform admins have the minimum permissions necessary to cancel a broadcast that might have been sent out accidentally.
2021-04-06 15:08:47 +01:00
mocker,
client_request,
service_one,
active_user_view_permissions,
):
"""
separate test for cancel_broadcast endpoint, because admin users are allowed to cancel broadcasts
"""
service_one['permissions'] += ['broadcast']
mocker.patch('app.user_api_client.get_user', return_value=active_user_view_permissions)
client_request.get(
'.cancel_broadcast_message',
service_id=SERVICE_ONE_ID,
_expected_status=403,
**{'broadcast_message_id': sample_uuid}
)
client_request.post(
'.cancel_broadcast_message',
service_id=SERVICE_ONE_ID,
_expected_status=403,
**{'broadcast_message_id': sample_uuid}
)
Add a version of the tour for live services At the moment if you’re invited to a live broadcast service you get the training mode tour. This is misleading, and could make people think they weren’t in danger of sending a real alert. This commit adds a short, 2 step tour for users invited to a live broadcast service.
2021-05-13 14:17:28 +01:00
@pytest.mark.parametrize('endpoint, step_index, expected_link_text, expected_link_href', (
('.broadcast_tour', 1, 'Continue', partial(url_for, '.broadcast_tour', step_index=2)),
('.broadcast_tour', 2, 'Continue', partial(url_for, '.broadcast_tour', step_index=3)),
('.broadcast_tour', 3, 'Continue', partial(url_for, '.broadcast_tour', step_index=4)),
('.broadcast_tour', 4, 'Continue', partial(url_for, '.broadcast_tour', step_index=5)),
('.broadcast_tour', 5, 'Continue', partial(url_for, '.service_dashboard')),
('.broadcast_tour', 6, 'Continue', partial(url_for, '.service_dashboard')),
('.broadcast_tour_live', 1, 'Continue', partial(url_for, '.broadcast_tour_live', step_index=2)),
('.broadcast_tour_live', 2, 'Continue', partial(url_for, '.service_dashboard')),
Refine broadcast tour based on research learnings We’ve shown the broadcast tour to a few users now. We’ve learned what concepts about broadcasting are and aren’t getting through. So what we’re emphasising here is: - the thing that appears on the phone (the ‘emergency alert’) not the technology (a ‘broadcast’) - how it’s different to other channels of messaging, eg text We’ve generally spent a lot more time on the content and illustrations this time around, so overall it’s should be clearer and shorter. This also expands the communication of training mode into the header, so it’s visible on every page (we can add another one for ‘live’ services later on).
2020-08-19 14:54:50 +01:00
))
def test_broadcast_tour_pages_have_continue_link(
client_request,
service_one,
Add a version of the tour for live services At the moment if you’re invited to a live broadcast service you get the training mode tour. This is misleading, and could make people think they weren’t in danger of sending a real alert. This commit adds a short, 2 step tour for users invited to a live broadcast service.
2021-05-13 14:17:28 +01:00
endpoint,
Refine broadcast tour based on research learnings We’ve shown the broadcast tour to a few users now. We’ve learned what concepts about broadcasting are and aren’t getting through. So what we’re emphasising here is: - the thing that appears on the phone (the ‘emergency alert’) not the technology (a ‘broadcast’) - how it’s different to other channels of messaging, eg text We’ve generally spent a lot more time on the content and illustrations this time around, so overall it’s should be clearer and shorter. This also expands the communication of training mode into the header, so it’s visible on every page (we can add another one for ‘live’ services later on).
2020-08-19 14:54:50 +01:00
step_index,
expected_link_text,
expected_link_href,
):
service_one['permissions'] += ['broadcast']
page = client_request.get(
Add a version of the tour for live services At the moment if you’re invited to a live broadcast service you get the training mode tour. This is misleading, and could make people think they weren’t in danger of sending a real alert. This commit adds a short, 2 step tour for users invited to a live broadcast service.
2021-05-13 14:17:28 +01:00
endpoint,
Refine broadcast tour based on research learnings We’ve shown the broadcast tour to a few users now. We’ve learned what concepts about broadcasting are and aren’t getting through. So what we’re emphasising here is: - the thing that appears on the phone (the ‘emergency alert’) not the technology (a ‘broadcast’) - how it’s different to other channels of messaging, eg text We’ve generally spent a lot more time on the content and illustrations this time around, so overall it’s should be clearer and shorter. This also expands the communication of training mode into the header, so it’s visible on every page (we can add another one for ‘live’ services later on).
2020-08-19 14:54:50 +01:00
service_id=SERVICE_ONE_ID,
step_index=step_index,
)
link = page.select_one('.banner-tour a')
assert normalize_spaces(link.text) == expected_link_text
assert link['href'] == expected_link_href(service_id=SERVICE_ONE_ID)
Combine tests using parametrize
2021-05-19 10:12:51 +01:00
@pytest.mark.parametrize('endpoint, step_index', (
pytest.param('.broadcast_tour', 1, marks=pytest.mark.xfail),
pytest.param('.broadcast_tour', 2, marks=pytest.mark.xfail),
pytest.param('.broadcast_tour', 3, marks=pytest.mark.xfail),
pytest.param('.broadcast_tour', 4, marks=pytest.mark.xfail),
('.broadcast_tour', 5),
('.broadcast_tour', 6),
('.broadcast_tour_live', 1),
('.broadcast_tour_live', 2),
Refine broadcast tour based on research learnings We’ve shown the broadcast tour to a few users now. We’ve learned what concepts about broadcasting are and aren’t getting through. So what we’re emphasising here is: - the thing that appears on the phone (the ‘emergency alert’) not the technology (a ‘broadcast’) - how it’s different to other channels of messaging, eg text We’ve generally spent a lot more time on the content and illustrations this time around, so overall it’s should be clearer and shorter. This also expands the communication of training mode into the header, so it’s visible on every page (we can add another one for ‘live’ services later on).
2020-08-19 14:54:50 +01:00
))
Combine tests using parametrize
2021-05-19 10:12:51 +01:00
def test_some_broadcast_tour_pages_show_service_name(
Refine broadcast tour based on research learnings We’ve shown the broadcast tour to a few users now. We’ve learned what concepts about broadcasting are and aren’t getting through. So what we’re emphasising here is: - the thing that appears on the phone (the ‘emergency alert’) not the technology (a ‘broadcast’) - how it’s different to other channels of messaging, eg text We’ve generally spent a lot more time on the content and illustrations this time around, so overall it’s should be clearer and shorter. This also expands the communication of training mode into the header, so it’s visible on every page (we can add another one for ‘live’ services later on).
2020-08-19 14:54:50 +01:00
client_request,
service_one,
Combine tests using parametrize
2021-05-19 10:12:51 +01:00
endpoint,
Refine broadcast tour based on research learnings We’ve shown the broadcast tour to a few users now. We’ve learned what concepts about broadcasting are and aren’t getting through. So what we’re emphasising here is: - the thing that appears on the phone (the ‘emergency alert’) not the technology (a ‘broadcast’) - how it’s different to other channels of messaging, eg text We’ve generally spent a lot more time on the content and illustrations this time around, so overall it’s should be clearer and shorter. This also expands the communication of training mode into the header, so it’s visible on every page (we can add another one for ‘live’ services later on).
2020-08-19 14:54:50 +01:00
step_index,
):
service_one['permissions'] += ['broadcast']
page = client_request.get(
Combine tests using parametrize
2021-05-19 10:12:51 +01:00
endpoint,
Refine broadcast tour based on research learnings We’ve shown the broadcast tour to a few users now. We’ve learned what concepts about broadcasting are and aren’t getting through. So what we’re emphasising here is: - the thing that appears on the phone (the ‘emergency alert’) not the technology (a ‘broadcast’) - how it’s different to other channels of messaging, eg text We’ve generally spent a lot more time on the content and illustrations this time around, so overall it’s should be clearer and shorter. This also expands the communication of training mode into the header, so it’s visible on every page (we can add another one for ‘live’ services later on).
2020-08-19 14:54:50 +01:00
service_id=SERVICE_ONE_ID,
step_index=step_index,
)
Refactor service name code to reduce duplication This makes the code shareable between: - the broadcast tour pages - the broadcast settings platform admin page - the regular service navigation On the training mode tour pages we don’t want to confuse people with the organisation name or _Switch service_ links, so those are omitted and the code is therefore slightly different.
2021-05-19 09:39:38 +01:00
assert normalize_spaces(
page.select_one('.navigation-service').text
).startswith(
Refine broadcast tour based on research learnings We’ve shown the broadcast tour to a few users now. We’ve learned what concepts about broadcasting are and aren’t getting through. So what we’re emphasising here is: - the thing that appears on the phone (the ‘emergency alert’) not the technology (a ‘broadcast’) - how it’s different to other channels of messaging, eg text We’ve generally spent a lot more time on the content and illustrations this time around, so overall it’s should be clearer and shorter. This also expands the communication of training mode into the header, so it’s visible on every page (we can add another one for ‘live’ services later on).
2020-08-19 14:54:50 +01:00
'service one Training'
)
Add government channel We have been asked to support the government channel so that: - it can be tested - the option to use it is available for the most severe of emergencies, where the public’s choice to opt-out is outweighed by the widespread risk to life
2021-05-11 09:50:18 +01:00
@pytest.mark.parametrize(
'trial_mode, channel, allowed_broadcast_provider, selector, expected_text, expected_tagged_text',
Allow provider_restriction to be None or "all" Until all the data is updated to always be "all", we have to handle the case of provider_restriction being set to None or "all" (which mean the same thing). The code can be tidied up once the broadcast provider_restriction is never None.
2021-05-10 14:35:18 +01:00
(
Add government channel We have been asked to support the government channel so that: - it can be tested - the option to use it is available for the most severe of emergencies, where the public’s choice to opt-out is outweighed by the widespread risk to life
2021-05-11 09:50:18 +01:00
(
True,
None,
Be explicit that ‘test’ goes out on real networks Adding ‘all networks’ whenever we mention the using the test channel without a restriction to a single network should help reinforce that this sends real alerts.
2021-05-12 11:33:09 +01:00
'all',
'.navigation-service-type.navigation-service-type--training',
'service one Training Switch service',
'Training',
),
(
True,
'test',
'all',
Add government channel We have been asked to support the government channel so that: - it can be tested - the option to use it is available for the most severe of emergencies, where the public’s choice to opt-out is outweighed by the widespread risk to life
2021-05-11 09:50:18 +01:00
'.navigation-service-type.navigation-service-type--training',
'service one Training Switch service',
'Training',
),
(
False,
'severe',
Be explicit that ‘test’ goes out on real networks Adding ‘all networks’ whenever we mention the using the test channel without a restriction to a single network should help reinforce that this sends real alerts.
2021-05-12 11:33:09 +01:00
'all',
Add government channel We have been asked to support the government channel so that: - it can be tested - the option to use it is available for the most severe of emergencies, where the public’s choice to opt-out is outweighed by the widespread risk to life
2021-05-11 09:50:18 +01:00
'.navigation-service-type.navigation-service-type--live',
Remove ‘(all networks)’ from settings label I don’t think we need to say (all networks) in the header. The real benefit of this change is forcing the platform admin person making the change to explicitly give their choice of network. And by not putting it in the label we don’t have future users from other organisations wondering if there’s some option other than ‘all networks’ they need to think about.
2021-06-01 17:55:17 +01:00
'service one Live Switch service',
'Live',
Add government channel We have been asked to support the government channel so that: - it can be tested - the option to use it is available for the most severe of emergencies, where the public’s choice to opt-out is outweighed by the widespread risk to life
2021-05-11 09:50:18 +01:00
),
Add support for the operator channel Was just in one of those meetings where it felt like writing this would take less time than I’d already spent talking about its relative priority… --- In the admin app you can already set the broadcast channel as 'test', 'severe' or 'government'. Aim: - Add the 'operator' channel to the list of channels you can pick for the admin app broadcast services Note: - The API already supports this - https://github.com/alphagov/notifications-api/pull/3262 - The CBC proxy does not yet support the operator channel and this will need a separate card. That card has not yet been written because the interface has not been agreed between us and the MNOs yet. - Will need to have the ability to select the operator channel for just a single MNO like we do for the other channels - If we add this, we shouldn't actually start using it until the MNO in question gives us the go ahead. --- https://www.pivotaltracker.com/story/show/178485177
2021-06-11 12:03:38 +01:00
(
False,
'operator',
'all',
'.navigation-service-type.navigation-service-type--operator',
'service one Operator Switch service',
'Operator',
),
(
False,
'operator',
'vodafone',
'.navigation-service-type.navigation-service-type--operator',
'service one Operator (Vodafone) Switch service',
'Operator (Vodafone)',
),
Add government channel We have been asked to support the government channel so that: - it can be tested - the option to use it is available for the most severe of emergencies, where the public’s choice to opt-out is outweighed by the widespread risk to life
2021-05-11 09:50:18 +01:00
(
False,
'test',
Be explicit that ‘test’ goes out on real networks Adding ‘all networks’ whenever we mention the using the test channel without a restriction to a single network should help reinforce that this sends real alerts.
2021-05-12 11:33:09 +01:00
'all',
Allow setting provider for any channel Previously we could only select a provider when using the test channel, but this is also required for others channels when we do tests on the production network with individual MNOs. In order to reduce duplication and improve consistency, I've reused the new broadcast_service_name_tag macro to show the setting.
2021-05-20 13:27:22 +01:00
'.navigation-service-type.navigation-service-type--test',
Remove ‘(all networks)’ from settings label I don’t think we need to say (all networks) in the header. The real benefit of this change is forcing the platform admin person making the change to explicitly give their choice of network. And by not putting it in the label we don’t have future users from other organisations wondering if there’s some option other than ‘all networks’ they need to think about.
2021-06-01 17:55:17 +01:00
'service one Test Switch service',
'Test',
Add government channel We have been asked to support the government channel so that: - it can be tested - the option to use it is available for the most severe of emergencies, where the public’s choice to opt-out is outweighed by the widespread risk to life
2021-05-11 09:50:18 +01:00
),
(
False,
'test',
Be explicit that ‘test’ goes out on real networks Adding ‘all networks’ whenever we mention the using the test channel without a restriction to a single network should help reinforce that this sends real alerts.
2021-05-12 11:33:09 +01:00
'vodafone',
Allow setting provider for any channel Previously we could only select a provider when using the test channel, but this is also required for others channels when we do tests on the production network with individual MNOs. In order to reduce duplication and improve consistency, I've reused the new broadcast_service_name_tag macro to show the setting.
2021-05-20 13:27:22 +01:00
'.navigation-service-type.navigation-service-type--test',
Refactor service name code to reduce duplication This makes the code shareable between: - the broadcast tour pages - the broadcast settings platform admin page - the regular service navigation On the training mode tour pages we don’t want to confuse people with the organisation name or _Switch service_ links, so those are omitted and the code is therefore slightly different.
2021-05-19 09:39:38 +01:00
'service one Test (Vodafone) Switch service',
'Test (Vodafone)',
Add government channel We have been asked to support the government channel so that: - it can be tested - the option to use it is available for the most severe of emergencies, where the public’s choice to opt-out is outweighed by the widespread risk to life
2021-05-11 09:50:18 +01:00
),
(
False,
'government',
'all',
Make the government channel visually distinct It’s really serious, so this sets it apart from the other live channels.
2021-05-12 11:50:30 +01:00
'.navigation-service-type.navigation-service-type--government',
Remove ‘(all networks)’ from settings label I don’t think we need to say (all networks) in the header. The real benefit of this change is forcing the platform admin person making the change to explicitly give their choice of network. And by not putting it in the label we don’t have future users from other organisations wondering if there’s some option other than ‘all networks’ they need to think about.
2021-06-01 17:55:17 +01:00
'service one Government Switch service',
'Government',
Allow setting provider for any channel Previously we could only select a provider when using the test channel, but this is also required for others channels when we do tests on the production network with individual MNOs. In order to reduce duplication and improve consistency, I've reused the new broadcast_service_name_tag macro to show the setting.
2021-05-20 13:27:22 +01:00
),
(
False,
'government',
'vodafone',
'.navigation-service-type.navigation-service-type--government',
'service one Government (Vodafone) Switch service',
'Government (Vodafone)',
),
(
False,
'severe',
'vodafone',
'.navigation-service-type.navigation-service-type--live',
'service one Live (Vodafone) Switch service',
'Live (Vodafone)',
Add government channel We have been asked to support the government channel so that: - it can be tested - the option to use it is available for the most severe of emergencies, where the public’s choice to opt-out is outweighed by the widespread risk to life
2021-05-11 09:50:18 +01:00
),
)
)
Allow setting provider for any channel Previously we could only select a provider when using the test channel, but this is also required for others channels when we do tests on the production network with individual MNOs. In order to reduce duplication and improve consistency, I've reused the new broadcast_service_name_tag macro to show the setting.
2021-05-20 13:27:22 +01:00
def test_broadcast_service_shows_channel_settings(
Show an indication that a broadcast service is live We want it to be very clear whether you’re in live or training mode because: - you may be switching back and forth between them - doing something in live mode when you think you’re in training mode would have… consequences By adding a label next to the service name you’ll will have some indication, on every page, which mode you are in. Style of the label is based on the ‘Tag’ component from the Design System: https://design-system.service.gov.uk/components/tag/#showing-multiple-statuses
2020-09-22 14:52:15 +01:00
client_request,
service_one,
mock_get_no_broadcast_messages,
trial_mode,
show allowed broadcast provider in the "training"/"live" window
2020-12-04 10:52:09 +00:00
allowed_broadcast_provider,
Add government channel We have been asked to support the government channel so that: - it can be tested - the option to use it is available for the most severe of emergencies, where the public’s choice to opt-out is outweighed by the widespread risk to life
2021-05-11 09:50:18 +01:00
channel,
Show an indication that a broadcast service is live We want it to be very clear whether you’re in live or training mode because: - you may be switching back and forth between them - doing something in live mode when you think you’re in training mode would have… consequences By adding a label next to the service name you’ll will have some indication, on every page, which mode you are in. Style of the label is based on the ‘Tag’ component from the Design System: https://design-system.service.gov.uk/components/tag/#showing-multiple-statuses
2020-09-22 14:52:15 +01:00
selector,
expected_text,
expected_tagged_text,
):
show allowed broadcast provider in the "training"/"live" window
2020-12-04 10:52:09 +00:00
service_one['allowed_broadcast_provider'] = allowed_broadcast_provider
Show an indication that a broadcast service is live We want it to be very clear whether you’re in live or training mode because: - you may be switching back and forth between them - doing something in live mode when you think you’re in training mode would have… consequences By adding a label next to the service name you’ll will have some indication, on every page, which mode you are in. Style of the label is based on the ‘Tag’ component from the Design System: https://design-system.service.gov.uk/components/tag/#showing-multiple-statuses
2020-09-22 14:52:15 +01:00
service_one['permissions'] += ['broadcast']
service_one['restricted'] = trial_mode
Add government channel We have been asked to support the government channel so that: - it can be tested - the option to use it is available for the most severe of emergencies, where the public’s choice to opt-out is outweighed by the widespread risk to life
2021-05-11 09:50:18 +01:00
service_one['broadcast_channel'] = channel
Show an indication that a broadcast service is live We want it to be very clear whether you’re in live or training mode because: - you may be switching back and forth between them - doing something in live mode when you think you’re in training mode would have… consequences By adding a label next to the service name you’ll will have some indication, on every page, which mode you are in. Style of the label is based on the ‘Tag’ component from the Design System: https://design-system.service.gov.uk/components/tag/#showing-multiple-statuses
2020-09-22 14:52:15 +01:00
page = client_request.get(
'.broadcast_dashboard',
service_id=SERVICE_ONE_ID,
)
assert normalize_spaces(
page.select_one('.navigation-service').text
) == (
expected_text
)
assert normalize_spaces(
page.select_one('.navigation-service').select_one(selector).text
) == (
expected_tagged_text
)
Add a version of the tour for live services At the moment if you’re invited to a live broadcast service you get the training mode tour. This is misleading, and could make people think they weren’t in danger of sending a real alert. This commit adds a short, 2 step tour for users invited to a live broadcast service.
2021-05-13 14:17:28 +01:00
@pytest.mark.parametrize('endpoint, step_index', (
('.broadcast_tour', 0),
('.broadcast_tour', 7),
('.broadcast_tour_live', 0),
('.broadcast_tour_live', 3),
))
Refine broadcast tour based on research learnings We’ve shown the broadcast tour to a few users now. We’ve learned what concepts about broadcasting are and aren’t getting through. So what we’re emphasising here is: - the thing that appears on the phone (the ‘emergency alert’) not the technology (a ‘broadcast’) - how it’s different to other channels of messaging, eg text We’ve generally spent a lot more time on the content and illustrations this time around, so overall it’s should be clearer and shorter. This also expands the communication of training mode into the header, so it’s visible on every page (we can add another one for ‘live’ services later on).
2020-08-19 14:54:50 +01:00
def test_broadcast_tour_page_404s_out_of_range(
client_request,
service_one,
Add a version of the tour for live services At the moment if you’re invited to a live broadcast service you get the training mode tour. This is misleading, and could make people think they weren’t in danger of sending a real alert. This commit adds a short, 2 step tour for users invited to a live broadcast service.
2021-05-13 14:17:28 +01:00
endpoint,
Refine broadcast tour based on research learnings We’ve shown the broadcast tour to a few users now. We’ve learned what concepts about broadcasting are and aren’t getting through. So what we’re emphasising here is: - the thing that appears on the phone (the ‘emergency alert’) not the technology (a ‘broadcast’) - how it’s different to other channels of messaging, eg text We’ve generally spent a lot more time on the content and illustrations this time around, so overall it’s should be clearer and shorter. This also expands the communication of training mode into the header, so it’s visible on every page (we can add another one for ‘live’ services later on).
2020-08-19 14:54:50 +01:00
step_index,
):
service_one['permissions'] += ['broadcast']
client_request.get(
Add a version of the tour for live services At the moment if you’re invited to a live broadcast service you get the training mode tour. This is misleading, and could make people think they weren’t in danger of sending a real alert. This commit adds a short, 2 step tour for users invited to a live broadcast service.
2021-05-13 14:17:28 +01:00
endpoint,
Refine broadcast tour based on research learnings We’ve shown the broadcast tour to a few users now. We’ve learned what concepts about broadcasting are and aren’t getting through. So what we’re emphasising here is: - the thing that appears on the phone (the ‘emergency alert’) not the technology (a ‘broadcast’) - how it’s different to other channels of messaging, eg text We’ve generally spent a lot more time on the content and illustrations this time around, so overall it’s should be clearer and shorter. This also expands the communication of training mode into the header, so it’s visible on every page (we can add another one for ‘live’ services later on).
2020-08-19 14:54:50 +01:00
service_id=SERVICE_ONE_ID,
step_index=step_index,
_expected_status=404,
)
Redirect from normal dashboard to broadcast dashboard 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.
2020-07-08 11:39:04 +01:00
def test_dashboard_redirects_to_broadcast_dashboard(
client_request,
service_one,
):
service_one['permissions'] += ['broadcast']
client_request.get(
'.service_dashboard',
service_id=SERVICE_ONE_ID,
_expected_redirect=url_for(
'.broadcast_dashboard',
service_id=SERVICE_ONE_ID,
_external=True,
),
),
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
def test_empty_broadcast_dashboard(
client_request,
service_one,
mock_get_no_broadcast_messages,
):
service_one['permissions'] += ['broadcast']
page = client_request.get(
'.broadcast_dashboard',
service_id=SERVICE_ONE_ID,
)
Combine current and pending broadcasts Splitting the dashboard into multiple sections was confusing, and people sometimes mistook the headings as labels, especially when a section was empty. It just wasn’t clear what the hierarchy of the page was. This commit combines the current and pending broadcasts into one list on the dashboard. Previous broadcasts have already moved to their own page.
2020-10-26 11:18:30 +00:00
assert normalize_spaces(page.select_one('h1').text) == (
'Current alerts'
)
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
assert [
Make list of areas on dashboard use full width When the list of areas is restricted to half the width of the page it starts to look pretty higgledy-piggledy when you have lots of areas or areas with very long names. To do this I’ve ripped out the table markup in favour of headings, paragraphs and lists. Probably pros and cons for each, but it was really hard to do the layout with the content in a table.
2020-10-27 15:16:27 +00:00
normalize_spaces(row.text) for row in page.select('.table-empty-message')
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
] == [
Combine current and pending broadcasts Splitting the dashboard into multiple sections was confusing, and people sometimes mistook the headings as labels, especially when a section was empty. It just wasn’t clear what the hierarchy of the page was. This commit combines the current and pending broadcasts into one list on the dashboard. Previous broadcasts have already moved to their own page.
2020-10-26 11:18:30 +00:00
'You do not have any current alerts',
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
]
Split out the tests for 'New alert' button on broadcast dashboards The 'New alert' button was being tested in the same tests as the tests for the page content for the broadcast dashboards. Now that you only see the button if you have the `create_broadcasts` permission, this adds a new test just for the button so that the test for the page content can be used for both broadcast permissions.
2021-07-23 14:47:17 +01:00
@pytest.mark.parametrize('user', [
create_active_user_approve_broadcasts_permissions(),
create_active_user_create_broadcasts_permissions(),
])
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
@freeze_time('2020-02-20 02:20')
Add a dashboard for broadcast services This is just a placeholder for now
2020-07-08 11:34:16 +01:00
def test_broadcast_dashboard(
client_request,
service_one,
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
mock_get_broadcast_messages,
Split out the tests for 'New alert' button on broadcast dashboards The 'New alert' button was being tested in the same tests as the tests for the page content for the broadcast dashboards. Now that you only see the button if you have the `create_broadcasts` permission, this adds a new test just for the button so that the test for the page content can be used for both broadcast permissions.
2021-07-23 14:47:17 +01:00
user,
Add a dashboard for broadcast services This is just a placeholder for now
2020-07-08 11:34:16 +01:00
):
service_one['permissions'] += ['broadcast']
Split out the tests for 'New alert' button on broadcast dashboards The 'New alert' button was being tested in the same tests as the tests for the page content for the broadcast dashboards. Now that you only see the button if you have the `create_broadcasts` permission, this adds a new test just for the button so that the test for the page content can be used for both broadcast permissions.
2021-07-23 14:47:17 +01:00
client_request.login(user)
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
page = client_request.get(
Add a dashboard for broadcast services This is just a placeholder for now
2020-07-08 11:34:16 +01:00
'.broadcast_dashboard',
service_id=SERVICE_ONE_ID,
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
)
fix tests
2020-07-22 15:15:23 +01:00
Make list of areas on dashboard use full width When the list of areas is restricted to half the width of the page it starts to look pretty higgledy-piggledy when you have lots of areas or areas with very long names. To do this I’ve ripped out the table markup in favour of headings, paragraphs and lists. Probably pros and cons for each, but it was really hard to do the layout with the content in a table.
2020-10-27 15:16:27 +00:00
assert len(page.select('.ajax-block-container')) == len(page.select('h1')) == 1
Remove previous broadcasts from the dashboard Since they have their own page now they don’t need to also appear on the dashboard.
2020-10-13 11:41:22 +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
assert [
Make list of areas on dashboard use full width When the list of areas is restricted to half the width of the page it starts to look pretty higgledy-piggledy when you have lots of areas or areas with very long names. To do this I’ve ripped out the table markup in favour of headings, paragraphs and lists. Probably pros and cons for each, but it was really hard to do the layout with the content in a table.
2020-10-27 15:16:27 +00:00
normalize_spaces(row.text)
for row in page.select('.ajax-block-container')[0].select('.file-list')
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
] == [
Make list of areas on dashboard use full width When the list of areas is restricted to half the width of the page it starts to look pretty higgledy-piggledy when you have lots of areas or areas with very long names. To do this I’ve ripped out the table markup in favour of headings, paragraphs and lists. Probably pros and cons for each, but it was really hard to do the layout with the content in a table.
2020-10-27 15:16:27 +00:00
'Half an hour ago This is a test Waiting for approval England Scotland',
'Hour and a half ago This is a test Waiting for approval England Scotland',
'Example template This is a test Live since today at 2:20am England Scotland',
'Example template This is a test Live since today at 1:20am England Scotland',
Show pending broadcasts on dashboard When we have an approval flow, `pending-approval` will be the state a broadcast is in between being a draft and broadcasting. This means it is the earliest stage at which a broadcast can appear on the dashboard, so this commit adds a new section at the top of the dashboard to display these broadcasts (since the dashboard is in a reverse chronological order). Rather than displaying the scheduled time, the extra information shown is the person who drafted the broadcast, since I reckon you’ll be coming to this page because they’ve asked you to approve their broadcast.
2020-07-17 08:07:40 +01:00
]
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
Use new permissions for the button on the broadcast dashboard The broadcast dashboards contain a button to create a new broadcast. This adds the new `create_broadcasts` permission as one of the permissions needed to see the button.
2021-06-28 08:33:27 +01:00
@pytest.mark.parametrize('user', [
create_platform_admin_user(),
create_active_user_view_permissions(),
create_active_user_approve_broadcasts_permissions(),
])
Add the new alert button to previous alerts page Feels like it should behave the same way as the current alerts page.
2021-01-18 16:46:13 +00:00
@pytest.mark.parametrize('endpoint', (
Add a separate page for rejected alerts We don’t want to mix these up with alerts that actually went out.
2021-04-08 13:09:29 +01:00
'.broadcast_dashboard', '.broadcast_dashboard_previous', '.broadcast_dashboard_rejected',
Add the new alert button to previous alerts page Feels like it should behave the same way as the current alerts page.
2021-01-18 16:46:13 +00:00
))
Use new permissions for the button on the broadcast dashboard The broadcast dashboards contain a button to create a new broadcast. This adds the new `create_broadcasts` permission as one of the permissions needed to see the button.
2021-06-28 08:33:27 +01:00
def test_broadcast_dashboard_does_not_have_button_if_user_does_not_have_permission_to_create_broadcast(
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
client_request,
service_one,
mock_get_broadcast_messages,
Add the new alert button to previous alerts page Feels like it should behave the same way as the current alerts page.
2021-01-18 16:46:13 +00:00
endpoint,
Use new permissions for the button on the broadcast dashboard The broadcast dashboards contain a button to create a new broadcast. This adds the new `create_broadcasts` permission as one of the permissions needed to see the button.
2021-06-28 08:33:27 +01:00
user,
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
):
Use new permissions for the button on the broadcast dashboard The broadcast dashboards contain a button to create a new broadcast. This adds the new `create_broadcasts` permission as one of the permissions needed to see the button.
2021-06-28 08:33:27 +01:00
client_request.login(user)
Admins won't see buttons for broadcast actions they can't do These actions are creating, accepting and rejecting broadcasts.
2021-04-14 18:13:18 +01:00
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
service_one['permissions'] += ['broadcast']
page = client_request.get(
Add the new alert button to previous alerts page Feels like it should behave the same way as the current alerts page.
2021-01-18 16:46:13 +00:00
endpoint,
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
service_id=SERVICE_ONE_ID,
)
assert not page.select('a.govuk-button')
Add a dashboard for broadcast services This is just a placeholder for now
2020-07-08 11:34:16 +01:00
Split out the tests for 'New alert' button on broadcast dashboards The 'New alert' button was being tested in the same tests as the tests for the page content for the broadcast dashboards. Now that you only see the button if you have the `create_broadcasts` permission, this adds a new test just for the button so that the test for the page content can be used for both broadcast permissions.
2021-07-23 14:47:17 +01:00
@pytest.mark.parametrize('endpoint', (
'.broadcast_dashboard', '.broadcast_dashboard_previous', '.broadcast_dashboard_rejected',
))
def test_broadcast_dashboard_has_new_alert_button_if_user_has_permission_to_create_broadcasts(
client_request,
service_one,
mock_get_broadcast_messages,
active_user_create_broadcasts_permission,
endpoint,
):
client_request.login(active_user_create_broadcasts_permission)
service_one['permissions'] += ['broadcast']
page = client_request.get(
endpoint,
service_id=SERVICE_ONE_ID,
)
button = page.select_one(
'.js-stick-at-bottom-when-scrolling a.govuk-button.govuk-button--secondary'
)
assert normalize_spaces(button.text) == 'New alert'
assert button['href'] == url_for(
'main.new_broadcast',
service_id=SERVICE_ONE_ID,
)
Make the broadcast dashboard update via AJAX Same technique as we use for other pages that update via AJAX. I’ve split the page up into separate chunks because the DiffDOM library we use finds it easier to work out what’s changed when there are fewer elements/a shallower tree.
2020-07-14 13:39:29 +01:00
@freeze_time('2020-02-20 02:20')
def test_broadcast_dashboard_json(
Stop using `logged_in_client` fixture We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `logged_in_client`. This is not as good because: - it returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests using `logged_in_client` to: use `client_request` instead.
2021-12-31 12:08:14 +00:00
client_request,
Make the broadcast dashboard update via AJAX Same technique as we use for other pages that update via AJAX. I’ve split the page up into separate chunks because the DiffDOM library we use finds it easier to work out what’s changed when there are fewer elements/a shallower tree.
2020-07-14 13:39:29 +01:00
service_one,
mock_get_broadcast_messages,
):
service_one['permissions'] += ['broadcast']
Stop using `logged_in_client` fixture We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `logged_in_client`. This is not as good because: - it returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests using `logged_in_client` to: use `client_request` instead.
2021-12-31 12:08:14 +00:00
response = client_request.get_response(
Make the broadcast dashboard update via AJAX Same technique as we use for other pages that update via AJAX. I’ve split the page up into separate chunks because the DiffDOM library we use finds it easier to work out what’s changed when there are fewer elements/a shallower tree.
2020-07-14 13:39:29 +01:00
'.broadcast_dashboard_updates',
service_id=SERVICE_ONE_ID,
Stop using `logged_in_client` fixture We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `logged_in_client`. This is not as good because: - it returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests using `logged_in_client` to: use `client_request` instead.
2021-12-31 12:08:14 +00:00
)
Make the broadcast dashboard update via AJAX Same technique as we use for other pages that update via AJAX. I’ve split the page up into separate chunks because the DiffDOM library we use finds it easier to work out what’s changed when there are fewer elements/a shallower tree.
2020-07-14 13:39:29 +01:00
json_response = json.loads(response.get_data(as_text=True))
Combine current and pending broadcasts Splitting the dashboard into multiple sections was confusing, and people sometimes mistook the headings as labels, especially when a section was empty. It just wasn’t clear what the hierarchy of the page was. This commit combines the current and pending broadcasts into one list on the dashboard. Previous broadcasts have already moved to their own page.
2020-10-26 11:18:30 +00:00
assert json_response.keys() == {'current_broadcasts'}
Make the broadcast dashboard update via AJAX Same technique as we use for other pages that update via AJAX. I’ve split the page up into separate chunks because the DiffDOM library we use finds it easier to work out what’s changed when there are fewer elements/a shallower tree.
2020-07-14 13:39:29 +01:00
Add status to alerts pending approval Now that pending alerts aren’t in their own section there’s nothing to label them as pending. So this commit replaces the extra metadata we show for a pending alert (the name of the person who created it, which was only ever a reckon) with an explicit label that says it’s waiting for approval.
2020-10-26 11:20:32 +00:00
assert 'Waiting for approval' in json_response['current_broadcasts']
Combine current and pending broadcasts Splitting the dashboard into multiple sections was confusing, and people sometimes mistook the headings as labels, especially when a section was empty. It just wasn’t clear what the hierarchy of the page was. This commit combines the current and pending broadcasts into one list on the dashboard. Previous broadcasts have already moved to their own page.
2020-10-26 11:18:30 +00:00
assert 'Live since today at 2:20am' in json_response['current_broadcasts']
Make the broadcast dashboard update via AJAX Same technique as we use for other pages that update via AJAX. I’ve split the page up into separate chunks because the DiffDOM library we use finds it easier to work out what’s changed when there are fewer elements/a shallower tree.
2020-07-14 13:39:29 +01:00
Split out the tests for 'New alert' button on broadcast dashboards The 'New alert' button was being tested in the same tests as the tests for the page content for the broadcast dashboards. Now that you only see the button if you have the `create_broadcasts` permission, this adds a new test just for the button so that the test for the page content can be used for both broadcast permissions.
2021-07-23 14:47:17 +01:00
@pytest.mark.parametrize('user', [
create_active_user_approve_broadcasts_permissions(),
create_active_user_create_broadcasts_permissions(),
])
Make a separate page for previous alerts Previous alerts are much less important than ones that are live or waiting for approval. Therefore we can make the dashboard more focused by moving previous alerts to their own page.
2020-10-13 11:40:20 +01:00
@freeze_time('2020-02-20 02:20')
def test_previous_broadcasts_page(
client_request,
service_one,
mock_get_broadcast_messages,
Split out the tests for 'New alert' button on broadcast dashboards The 'New alert' button was being tested in the same tests as the tests for the page content for the broadcast dashboards. Now that you only see the button if you have the `create_broadcasts` permission, this adds a new test just for the button so that the test for the page content can be used for both broadcast permissions.
2021-07-23 14:47:17 +01:00
user,
Make a separate page for previous alerts Previous alerts are much less important than ones that are live or waiting for approval. Therefore we can make the dashboard more focused by moving previous alerts to their own page.
2020-10-13 11:40:20 +01:00
):
service_one['permissions'] += ['broadcast']
Split out the tests for 'New alert' button on broadcast dashboards The 'New alert' button was being tested in the same tests as the tests for the page content for the broadcast dashboards. Now that you only see the button if you have the `create_broadcasts` permission, this adds a new test just for the button so that the test for the page content can be used for both broadcast permissions.
2021-07-23 14:47:17 +01:00
client_request.login(user)
Make a separate page for previous alerts Previous alerts are much less important than ones that are live or waiting for approval. Therefore we can make the dashboard more focused by moving previous alerts to their own page.
2020-10-13 11:40:20 +01:00
page = client_request.get(
'.broadcast_dashboard_previous',
service_id=SERVICE_ONE_ID,
)
assert normalize_spaces(page.select_one('main h1').text) == (
Change previous to past
2021-07-05 13:49:36 +01:00
'Past alerts'
Make a separate page for previous alerts Previous alerts are much less important than ones that are live or waiting for approval. Therefore we can make the dashboard more focused by moving previous alerts to their own page.
2020-10-13 11:40:20 +01:00
)
Make list of areas on dashboard use full width When the list of areas is restricted to half the width of the page it starts to look pretty higgledy-piggledy when you have lots of areas or areas with very long names. To do this I’ve ripped out the table markup in favour of headings, paragraphs and lists. Probably pros and cons for each, but it was really hard to do the layout with the content in a table.
2020-10-27 15:16:27 +00:00
assert len(page.select('.ajax-block-container')) == 1
Make a separate page for previous alerts Previous alerts are much less important than ones that are live or waiting for approval. Therefore we can make the dashboard more focused by moving previous alerts to their own page.
2020-10-13 11:40:20 +01:00
assert [
Make list of areas on dashboard use full width When the list of areas is restricted to half the width of the page it starts to look pretty higgledy-piggledy when you have lots of areas or areas with very long names. To do this I’ve ripped out the table markup in favour of headings, paragraphs and lists. Probably pros and cons for each, but it was really hard to do the layout with the content in a table.
2020-10-27 15:16:27 +00:00
normalize_spaces(row.text)
for row in page.select('.ajax-block-container')[0].select('.file-list')
Make a separate page for previous alerts Previous alerts are much less important than ones that are live or waiting for approval. Therefore we can make the dashboard more focused by moving previous alerts to their own page.
2020-10-13 11:40:20 +01:00
] == [
Remove verbs from old alerts Now we’ve split the old alerts onto two pages the verbs (‘Broadcast’ and ‘Rejected’) will always be the same for each alert – so they’re not adding any differentiation. The specifics of what the datetime means is available on the page for each alert. Removing the verbs makes the page a bit less cluttered and makes it easier to scan down the right hand column.
2021-04-08 13:46:40 +01:00
'Example template This is a test Yesterday at 2:20pm England Scotland',
'Example template This is a test Yesterday at 2:20am England Scotland',
Make a separate page for previous alerts Previous alerts are much less important than ones that are live or waiting for approval. Therefore we can make the dashboard more focused by moving previous alerts to their own page.
2020-10-13 11:40:20 +01:00
]
Split out the tests for 'New alert' button on broadcast dashboards The 'New alert' button was being tested in the same tests as the tests for the page content for the broadcast dashboards. Now that you only see the button if you have the `create_broadcasts` permission, this adds a new test just for the button so that the test for the page content can be used for both broadcast permissions.
2021-07-23 14:47:17 +01:00
@pytest.mark.parametrize('user', [
create_active_user_approve_broadcasts_permissions(),
create_active_user_create_broadcasts_permissions(),
])
Add a separate page for rejected alerts We don’t want to mix these up with alerts that actually went out.
2021-04-08 13:09:29 +01:00
@freeze_time('2020-02-20 02:20')
def test_rejected_broadcasts_page(
client_request,
service_one,
mock_get_broadcast_messages,
Split out the tests for 'New alert' button on broadcast dashboards The 'New alert' button was being tested in the same tests as the tests for the page content for the broadcast dashboards. Now that you only see the button if you have the `create_broadcasts` permission, this adds a new test just for the button so that the test for the page content can be used for both broadcast permissions.
2021-07-23 14:47:17 +01:00
user,
Add a separate page for rejected alerts We don’t want to mix these up with alerts that actually went out.
2021-04-08 13:09:29 +01:00
):
service_one['permissions'] += ['broadcast']
Split out the tests for 'New alert' button on broadcast dashboards The 'New alert' button was being tested in the same tests as the tests for the page content for the broadcast dashboards. Now that you only see the button if you have the `create_broadcasts` permission, this adds a new test just for the button so that the test for the page content can be used for both broadcast permissions.
2021-07-23 14:47:17 +01:00
client_request.login(user)
Add a separate page for rejected alerts We don’t want to mix these up with alerts that actually went out.
2021-04-08 13:09:29 +01:00
page = client_request.get(
'.broadcast_dashboard_rejected',
service_id=SERVICE_ONE_ID,
)
assert normalize_spaces(page.select_one('main h1').text) == (
'Rejected alerts'
)
assert len(page.select('.ajax-block-container')) == 1
assert [
normalize_spaces(row.text)
for row in page.select('.ajax-block-container')[0].select('.file-list')
] == [
Remove verbs from old alerts Now we’ve split the old alerts onto two pages the verbs (‘Broadcast’ and ‘Rejected’) will always be the same for each alert – so they’re not adding any differentiation. The specifics of what the datetime means is available on the page for each alert. Removing the verbs makes the page a bit less cluttered and makes it easier to scan down the right hand column.
2021-04-08 13:46:40 +01:00
'Example template This is a test Today at 1:20am England Scotland',
Add a separate page for rejected alerts We don’t want to mix these up with alerts that actually went out.
2021-04-08 13:09:29 +01:00
]
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
def test_new_broadcast_page(
client_request,
service_one,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
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
):
service_one['permissions'] += ['broadcast']
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
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
page = client_request.get(
'.new_broadcast',
service_id=SERVICE_ONE_ID,
)
assert normalize_spaces(page.select_one('h1').text) == 'New alert'
form = page.select_one('form')
assert form['method'] == 'post'
assert 'action' not in form
assert [
(
choice.select_one('input')['name'],
choice.select_one('input')['value'],
normalize_spaces(choice.select_one('label').text),
)
for choice in form.select('.govuk-radios__item')
] == [
('content', 'freeform', 'Write your own message'),
('content', 'template', 'Use a template'),
]
@pytest.mark.parametrize('value, expected_redirect_endpoint', (
('freeform', 'main.write_new_broadcast'),
('template', 'main.choose_template'),
))
def test_new_broadcast_page_redirects(
client_request,
service_one,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
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
value,
expected_redirect_endpoint,
):
service_one['permissions'] += ['broadcast']
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
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
client_request.post(
'.new_broadcast',
service_id=SERVICE_ONE_ID,
_data={
'content': value,
},
_expected_redirect=url_for(
expected_redirect_endpoint,
service_id=SERVICE_ONE_ID,
_external=True,
)
)
def test_write_new_broadcast_page(
client_request,
service_one,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
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
):
service_one['permissions'] += ['broadcast']
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
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
page = client_request.get(
'.write_new_broadcast',
service_id=SERVICE_ONE_ID,
)
assert normalize_spaces(page.select_one('h1').text) == 'New alert'
form = page.select_one('form')
assert form['method'] == 'post'
assert 'action' not in form
Change ‘title’ to ‘reference’ when writing alert On the screen where you write an alert without a template Andy pointed out that ‘title’ feels bit out of place. We chose this because ‘Template name’ definitely didn’t fit, but I agree that reference is better. Via https://trello.com/c/EqUln5yD/60-changing-title-to-reference-for-alert-template-new-message
2021-10-18 15:43:01 +01:00
assert normalize_spaces(page.select_one('label[for=name]').text) == 'Reference'
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
assert page.select_one('input[type=text]')['name'] == 'name'
Change ‘title’ to ‘reference’ when writing alert On the screen where you write an alert without a template Andy pointed out that ‘title’ feels bit out of place. We chose this because ‘Template name’ definitely didn’t fit, but I agree that reference is better. Via https://trello.com/c/EqUln5yD/60-changing-title-to-reference-for-alert-template-new-message
2021-10-18 15:43:01 +01:00
assert normalize_spaces(page.select_one('label[for=template_content]').text) == 'Message'
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
assert page.select_one('textarea')['name'] == 'template_content'
assert page.select_one('textarea')['data-module'] == 'enhanced-textbox'
assert page.select_one('textarea')['data-highlight-placeholders'] == 'false'
assert (
page.select_one('[data-module=update-status]')['data-updates-url']
) == url_for(
'.count_content_length',
service_id=SERVICE_ONE_ID,
template_type='broadcast',
)
assert (
page.select_one('[data-module=update-status]')['data-target']
) == (
page.select_one('textarea')['id']
) == (
'template_content'
)
assert (
page.select_one('[data-module=update-status]')['aria-live']
) == (
'polite'
)
def test_write_new_broadcast_posts(
client_request,
service_one,
mock_create_broadcast_message,
fake_uuid,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
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
):
service_one['permissions'] += ['broadcast']
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
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
client_request.post(
'.write_new_broadcast',
service_id=SERVICE_ONE_ID,
_data={
'name': 'My new alert',
'template_content': 'This is a test',
},
_expected_redirect=url_for(
Remove empty state step before choosing areas We had some kind of idea that having this empty page would introduce the idea of choosing areas and reinforce that you are building up a list of areas. But since the journey is now so simple with the button to create an alert directly on the dashboard page, maybe people don’t need this extra orientation.
2021-07-05 14:33:02 +01:00
'.choose_broadcast_library',
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
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
_external=True,
),
)
mock_create_broadcast_message.assert_called_once_with(
service_id=SERVICE_ONE_ID,
reference='My new alert',
content='This is a test',
template_id=None,
)
@pytest.mark.parametrize('content, expected_error_message', (
('', 'Cannot be empty'),
('ŵ' * 616, 'Content must be 615 characters or fewer because it contains ŵ'),
('w' * 1_396, 'Content must be 1,395 characters or fewer'),
('hello ((name))', 'You can’t use ((double brackets)) to personalise this message'),
))
def test_write_new_broadcast_bad_content(
client_request,
service_one,
mock_create_broadcast_message,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
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,
expected_error_message,
):
service_one['permissions'] += ['broadcast']
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
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
page = client_request.post(
'.write_new_broadcast',
service_id=SERVICE_ONE_ID,
_data={
'name': 'My new alert',
'template_content': content,
},
_expected_status=200,
)
assert normalize_spaces(
page.select_one('.error-message').text
) == (
expected_error_message
)
assert mock_create_broadcast_message.called is False
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
def test_broadcast_page(
client_request,
service_one,
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
fake_uuid,
mock_create_broadcast_message,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
):
service_one['permissions'] += ['broadcast']
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
client_request.get(
'.broadcast',
service_id=SERVICE_ONE_ID,
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
template_id=fake_uuid,
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
_expected_redirect=url_for(
Remove empty state step before choosing areas We had some kind of idea that having this empty page would introduce the idea of choosing areas and reinforce that you are building up a list of areas. But since the journey is now so simple with the button to create an alert directly on the dashboard page, maybe people don’t need this extra orientation.
2021-07-05 14:33:02 +01:00
'.choose_broadcast_library',
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
service_id=SERVICE_ONE_ID,
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=fake_uuid,
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
_external=True,
),
),
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
@pytest.mark.parametrize('areas_selected, areas_listed, estimates', (
([
'ctry19-E92000001',
'ctry19-S92000003',
], [
Replace 'x' psuedo element with SVG The current link button for removing an area is created using a psuedo element with an 'x' as content. The inline box for the 'x' overlapped its parent. This is visible in high contrast mode, breaking the parent's border. Despite existing in CSS, the 'x' is also announced by screen readers, which is not what we want. This changes it to be an inline SVG with a role of image. It doesn't require as large an inline box so doesn't cause visual issues in high contrast modes. It also means we can set it's label similar to how you would an image's alt text, giving us control over what is announced by screen readers. This commit also includes some extra CSS, targeting high contrast modes, giving the link button the following when viewed in those modes: - a complete border so it is distinguishable from the list item - a focus style
2021-10-21 13:26:40 +01:00
'England Remove England',
'Scotland Remove Scotland',
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
], [
Update utils to do linear transformation of polygons Brings in https://github.com/alphagov/notifications-utils/pull/889/files At the moment, we are not doing any transformation of features before applying geometric algorithms to them. This is, in effect, assuming that the earth is flat. This new version of utils implements the transformation of our polygons to a Cartesian plane. In other words, it converts them from being defined in spherical degrees to metres. For the admin app this means we need to convert places where the code expects things to be measured in degrees to work in metres instead.
2021-08-03 18:46:30 +01:00
'An area of 100,000 square miles Will get the alert',
'An extra area of 6,000 square miles is Likely to get the alert',
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
'40,000,000 phones estimated',
]),
([
'wd20-E05003224',
'wd20-E05003225',
'wd20-E05003227',
'wd20-E05003228',
'wd20-E05003229',
], [
Replace 'x' psuedo element with SVG The current link button for removing an area is created using a psuedo element with an 'x' as content. The inline box for the 'x' overlapped its parent. This is visible in high contrast mode, breaking the parent's border. Despite existing in CSS, the 'x' is also announced by screen readers, which is not what we want. This changes it to be an inline SVG with a role of image. It doesn't require as large an inline box so doesn't cause visual issues in high contrast modes. It also means we can set it's label similar to how you would an image's alt text, giving us control over what is announced by screen readers. This commit also includes some extra CSS, targeting high contrast modes, giving the link button the following when viewed in those modes: - a complete border so it is distinguishable from the list item - a focus style
2021-10-21 13:26:40 +01:00
'Penrith Carleton Remove Penrith Carleton',
'Penrith East Remove Penrith East',
'Penrith Pategill Remove Penrith Pategill',
'Penrith South Remove Penrith South',
'Penrith West Remove Penrith West',
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
], [
Update utils to do linear transformation of polygons Brings in https://github.com/alphagov/notifications-utils/pull/889/files At the moment, we are not doing any transformation of features before applying geometric algorithms to them. This is, in effect, assuming that the earth is flat. This new version of utils implements the transformation of our polygons to a Cartesian plane. In other words, it converts them from being defined in spherical degrees to metres. For the admin app this means we need to convert places where the code expects things to be measured in degrees to work in metres instead.
2021-08-03 18:46:30 +01:00
'An area of 4 square miles Will get the alert',
'An extra area of 10 square miles is Likely to get the alert',
Use CustomBroadcastArea to estimate phones in bleed area Our current assumption is that the bleed area has the same population density as the broadcast area. This is particularly naïve when: - the bleed area overlaps the sea – no-one lives in the sea - the broadcast area is a village and the bleed area is the surrounding countryside - the broadcast area is adjacent to a densely populated area like a city We can be smarter about this now that we have a way of determining the number of phones in an arbitrary area, based on the known areas that we have population data about. Calculating the population in an overlap is a slightly more intensive calculation. So we only doing it for areas which are smaller enough that it doesn’t slow things down too much. For larger areas we still use the more naïve algorithm.
2021-06-24 08:43:35 +01:00
'9,000 to 10,000 phones',
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
]),
([
'lad20-E09000019',
], [
Replace 'x' psuedo element with SVG The current link button for removing an area is created using a psuedo element with an 'x' as content. The inline box for the 'x' overlapped its parent. This is visible in high contrast mode, breaking the parent's border. Despite existing in CSS, the 'x' is also announced by screen readers, which is not what we want. This changes it to be an inline SVG with a role of image. It doesn't require as large an inline box so doesn't cause visual issues in high contrast modes. It also means we can set it's label similar to how you would an image's alt text, giving us control over what is announced by screen readers. This commit also includes some extra CSS, targeting high contrast modes, giving the link button the following when viewed in those modes: - a complete border so it is distinguishable from the list item - a focus style
2021-10-21 13:26:40 +01:00
'Islington Remove Islington',
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
], [
Update utils to do linear transformation of polygons Brings in https://github.com/alphagov/notifications-utils/pull/889/files At the moment, we are not doing any transformation of features before applying geometric algorithms to them. This is, in effect, assuming that the earth is flat. This new version of utils implements the transformation of our polygons to a Cartesian plane. In other words, it converts them from being defined in spherical degrees to metres. For the admin app this means we need to convert places where the code expects things to be measured in degrees to work in metres instead.
2021-08-03 18:46:30 +01:00
'An area of 6 square miles Will get the alert',
'An extra area of 4 square miles is Likely to get the alert',
'200,000 to 600,000 phones',
Use CustomBroadcastArea to estimate phones in bleed area Our current assumption is that the bleed area has the same population density as the broadcast area. This is particularly naïve when: - the bleed area overlaps the sea – no-one lives in the sea - the broadcast area is a village and the bleed area is the surrounding countryside - the broadcast area is adjacent to a densely populated area like a city We can be smarter about this now that we have a way of determining the number of phones in an arbitrary area, based on the known areas that we have population data about. Calculating the population in an overlap is a slightly more intensive calculation. So we only doing it for areas which are smaller enough that it doesn’t slow things down too much. For larger areas we still use the more naïve algorithm.
2021-06-24 08:43:35 +01:00
]),
([
'ctyua19-E10000019',
], [
Replace 'x' psuedo element with SVG The current link button for removing an area is created using a psuedo element with an 'x' as content. The inline box for the 'x' overlapped its parent. This is visible in high contrast mode, breaking the parent's border. Despite existing in CSS, the 'x' is also announced by screen readers, which is not what we want. This changes it to be an inline SVG with a role of image. It doesn't require as large an inline box so doesn't cause visual issues in high contrast modes. It also means we can set it's label similar to how you would an image's alt text, giving us control over what is announced by screen readers. This commit also includes some extra CSS, targeting high contrast modes, giving the link button the following when viewed in those modes: - a complete border so it is distinguishable from the list item - a focus style
2021-10-21 13:26:40 +01:00
'Lincolnshire Remove Lincolnshire',
Use CustomBroadcastArea to estimate phones in bleed area Our current assumption is that the bleed area has the same population density as the broadcast area. This is particularly naïve when: - the bleed area overlaps the sea – no-one lives in the sea - the broadcast area is a village and the bleed area is the surrounding countryside - the broadcast area is adjacent to a densely populated area like a city We can be smarter about this now that we have a way of determining the number of phones in an arbitrary area, based on the known areas that we have population data about. Calculating the population in an overlap is a slightly more intensive calculation. So we only doing it for areas which are smaller enough that it doesn’t slow things down too much. For larger areas we still use the more naïve algorithm.
2021-06-24 08:43:35 +01:00
], [
Update utils to do linear transformation of polygons Brings in https://github.com/alphagov/notifications-utils/pull/889/files At the moment, we are not doing any transformation of features before applying geometric algorithms to them. This is, in effect, assuming that the earth is flat. This new version of utils implements the transformation of our polygons to a Cartesian plane. In other words, it converts them from being defined in spherical degrees to metres. For the admin app this means we need to convert places where the code expects things to be measured in degrees to work in metres instead.
2021-08-03 18:46:30 +01:00
'An area of 2,000 square miles Will get the alert',
'An extra area of 500 square miles is Likely to get the alert',
Use CustomBroadcastArea to estimate phones in bleed area Our current assumption is that the bleed area has the same population density as the broadcast area. This is particularly naïve when: - the bleed area overlaps the sea – no-one lives in the sea - the broadcast area is a village and the bleed area is the surrounding countryside - the broadcast area is adjacent to a densely populated area like a city We can be smarter about this now that we have a way of determining the number of phones in an arbitrary area, based on the known areas that we have population data about. Calculating the population in an overlap is a slightly more intensive calculation. So we only doing it for areas which are smaller enough that it doesn’t slow things down too much. For larger areas we still use the more naïve algorithm.
2021-06-24 08:43:35 +01:00
'500,000 to 600,000 phones',
]),
([
'ctyua19-E10000019',
'ctyua19-E10000023'
], [
Replace 'x' psuedo element with SVG The current link button for removing an area is created using a psuedo element with an 'x' as content. The inline box for the 'x' overlapped its parent. This is visible in high contrast mode, breaking the parent's border. Despite existing in CSS, the 'x' is also announced by screen readers, which is not what we want. This changes it to be an inline SVG with a role of image. It doesn't require as large an inline box so doesn't cause visual issues in high contrast modes. It also means we can set it's label similar to how you would an image's alt text, giving us control over what is announced by screen readers. This commit also includes some extra CSS, targeting high contrast modes, giving the link button the following when viewed in those modes: - a complete border so it is distinguishable from the list item - a focus style
2021-10-21 13:26:40 +01:00
'Lincolnshire Remove Lincolnshire', 'North Yorkshire Remove North Yorkshire',
Use CustomBroadcastArea to estimate phones in bleed area Our current assumption is that the bleed area has the same population density as the broadcast area. This is particularly naïve when: - the bleed area overlaps the sea – no-one lives in the sea - the broadcast area is a village and the bleed area is the surrounding countryside - the broadcast area is adjacent to a densely populated area like a city We can be smarter about this now that we have a way of determining the number of phones in an arbitrary area, based on the known areas that we have population data about. Calculating the population in an overlap is a slightly more intensive calculation. So we only doing it for areas which are smaller enough that it doesn’t slow things down too much. For larger areas we still use the more naïve algorithm.
2021-06-24 08:43:35 +01:00
], [
Update utils to do linear transformation of polygons Brings in https://github.com/alphagov/notifications-utils/pull/889/files At the moment, we are not doing any transformation of features before applying geometric algorithms to them. This is, in effect, assuming that the earth is flat. This new version of utils implements the transformation of our polygons to a Cartesian plane. In other words, it converts them from being defined in spherical degrees to metres. For the admin app this means we need to convert places where the code expects things to be measured in degrees to work in metres instead.
2021-08-03 18:46:30 +01:00
'An area of 6,000 square miles Will get the alert',
'An extra area of 1,000 square miles is Likely to get the alert',
Use CustomBroadcastArea to estimate phones in bleed area Our current assumption is that the bleed area has the same population density as the broadcast area. This is particularly naïve when: - the bleed area overlaps the sea – no-one lives in the sea - the broadcast area is a village and the bleed area is the surrounding countryside - the broadcast area is adjacent to a densely populated area like a city We can be smarter about this now that we have a way of determining the number of phones in an arbitrary area, based on the known areas that we have population data about. Calculating the population in an overlap is a slightly more intensive calculation. So we only doing it for areas which are smaller enough that it doesn’t slow things down too much. For larger areas we still use the more naïve algorithm.
2021-06-24 08:43:35 +01:00
'1,000,000 phones estimated',
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
]),
))
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
def test_preview_broadcast_areas_page(
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
mocker,
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
client_request,
service_one,
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
fake_uuid,
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
areas_selected,
areas_listed,
estimates,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
):
service_one['permissions'] += ['broadcast']
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
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
template_id=fake_uuid,
created_by_id=fake_uuid,
service_id=SERVICE_ONE_ID,
status='draft',
Stop saying "areas" when we mean "area_ids" "areas" normally means an instance of BroadcastArea or similar, so we should be more accurate to avoid confusion.
2021-08-26 10:42:20 +01:00
area_ids=areas_selected,
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
),
)
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
Add estimated areas for non-visual users Since the key relies on visual association between the shapes on the maps and the styling of the key, it won’t work for non-visual users. An alternative way of giving them the same information is by providing the size of the area numerically.
2020-09-08 16:35:03 +01:00
page = client_request.get(
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
'.preview_broadcast_areas',
service_id=SERVICE_ONE_ID,
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=fake_uuid,
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
)
Add estimated areas for non-visual users Since the key relies on visual association between the shapes on the maps and the styling of the key, it won’t work for non-visual users. An alternative way of giving them the same information is by providing the size of the area numerically.
2020-09-08 16:35:03 +01:00
assert [
normalize_spaces(item.text)
for item in page.select('ul.area-list li.area-list-item')
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
] == areas_listed
Add estimated areas for non-visual users Since the key relies on visual association between the shapes on the maps and the styling of the key, it won’t work for non-visual users. An alternative way of giving them the same information is by providing the size of the area numerically.
2020-09-08 16:35:03 +01:00
Rename CSS classes for consistency This prefixes everything to do with areas/the map with `area-list`, so from looking at one element you know which `.scss` file will contain the relevant code.
2020-10-05 13:47:21 +01:00
assert len(page.select('#area-list-map')) == 1
Add estimated areas for non-visual users Since the key relies on visual association between the shapes on the maps and the styling of the key, it won’t work for non-visual users. An alternative way of giving them the same information is by providing the size of the area numerically.
2020-09-08 16:35:03 +01:00
assert [
normalize_spaces(item.text)
Change map key items from list to paragraphs I recently found that there is a problem with the overuse of lists online for sequences of content that don't need to be in a list. I think that's what we're doing with our map key. The problem is large enough that browsers include heuristics to determine if lists should be presented as such to the accessibility API (and so to assistive tech' like screen readers). This thread contains more details: https://twitter.com/cookiecrook/status/1337226933822603270 Based on the metric described in the thread: 'If all of the styles that make it “list-like” have been removed, it’s no longer relevant to convey it as a list.' ...or 'if a sighted user doesn’t need to know it’s a list, why would a screen reader user need to know or want to know?' Based on that, I think the items in our map key should be paragraphs, not items in a list. Also, they read really well as sentences when announced by a screen reader, partly because of the extra (hidden) info @quis added to them. This also doesn't change their visual appearance.
2021-10-07 14:29:51 +01:00
for item in page.select('.area-list-key')
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
] == estimates
Add estimated areas for non-visual users Since the key relies on visual association between the shapes on the maps and the styling of the key, it won’t work for non-visual users. An alternative way of giving them the same information is by providing the size of the area numerically.
2020-09-08 16:35:03 +01:00
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
Estimate number of phones in an arbitrary polygon We want to know how many phones are in a user-supplied polygon, so we can show the impact of a broadcast, in the same way that we do when users pick areas from our library. We already know how many phones are in each electoral ward. But there are challenges with an arbitrary polygon: - where it does overlap a ward, the overlap could be partial - it could overlap more than one ward - finding out which wards it overlaps by brute force (looping through all the wards and seeing which ones intersect with our polygon) would be way to slow to do in real time Instead we can use a data structure called an R-tree[1] to build an index which provides a much, much faster way of looking up which polygons overlap another. We can build this tree in advance and save it somewhere, which means there’s a lot of computation we don’t need to do in real time. The R-tree returns a set of objects (ward IDs) which we can go and look up in our library of electoral wards. These wards will be the ones that might have some overlap with our custom polygon. Once we have this small set of wards which might overlap our ward, we can look at the size of the area of overlap (relative to the size of the whole ward) and multiply that by the known count of phones in that ward to get an approximation of the count of phones in the overlap area. Summing these approximations give an estimate for the whole area of the custom polygon. 1. https://en.wikipedia.org/wiki/R-tree
2021-03-18 23:02:32 +00:00
@pytest.mark.parametrize('polygons, expected_list_items', (
(
[
[[1, 2], [3, 4], [5, 6]],
[[7, 8], [9, 10], [11, 12]],
],
[
Update utils to do linear transformation of polygons Brings in https://github.com/alphagov/notifications-utils/pull/889/files At the moment, we are not doing any transformation of features before applying geometric algorithms to them. This is, in effect, assuming that the earth is flat. This new version of utils implements the transformation of our polygons to a Cartesian plane. In other words, it converts them from being defined in spherical degrees to metres. For the admin app this means we need to convert places where the code expects things to be measured in degrees to work in metres instead.
2021-08-03 18:46:30 +01:00
'An area of 1,000 square miles Will get the alert',
Remove false precision from area estimates We give estimates of the area for those who can’t see the map. These estimates were needlessly precise, gave a false sense of accuracy and were causing intermittent test failures between different environments. This commit rounds them in the same way that we round the count of phones.
2021-06-24 16:54:08 +01:00
'An extra area of 1,000 square miles is Likely to get the alert',
Estimate number of phones in an arbitrary polygon We want to know how many phones are in a user-supplied polygon, so we can show the impact of a broadcast, in the same way that we do when users pick areas from our library. We already know how many phones are in each electoral ward. But there are challenges with an arbitrary polygon: - where it does overlap a ward, the overlap could be partial - it could overlap more than one ward - finding out which wards it overlaps by brute force (looping through all the wards and seeing which ones intersect with our polygon) would be way to slow to do in real time Instead we can use a data structure called an R-tree[1] to build an index which provides a much, much faster way of looking up which polygons overlap another. We can build this tree in advance and save it somewhere, which means there’s a lot of computation we don’t need to do in real time. The R-tree returns a set of objects (ward IDs) which we can go and look up in our library of electoral wards. These wards will be the ones that might have some overlap with our custom polygon. Once we have this small set of wards which might overlap our ward, we can look at the size of the area of overlap (relative to the size of the whole ward) and multiply that by the known count of phones in that ward to get an approximation of the count of phones in the overlap area. Summing these approximations give an estimate for the whole area of the custom polygon. 1. https://en.wikipedia.org/wiki/R-tree
2021-03-18 23:02:32 +00:00
'Unknown number of phones',
]
),
(
[BRISTOL],
[
Update utils to do linear transformation of polygons Brings in https://github.com/alphagov/notifications-utils/pull/889/files At the moment, we are not doing any transformation of features before applying geometric algorithms to them. This is, in effect, assuming that the earth is flat. This new version of utils implements the transformation of our polygons to a Cartesian plane. In other words, it converts them from being defined in spherical degrees to metres. For the admin app this means we need to convert places where the code expects things to be measured in degrees to work in metres instead.
2021-08-03 18:46:30 +01:00
'An area of 4 square miles Will get the alert',
'An extra area of 3 square miles is Likely to get the alert',
Estimate number of phones in an arbitrary polygon We want to know how many phones are in a user-supplied polygon, so we can show the impact of a broadcast, in the same way that we do when users pick areas from our library. We already know how many phones are in each electoral ward. But there are challenges with an arbitrary polygon: - where it does overlap a ward, the overlap could be partial - it could overlap more than one ward - finding out which wards it overlaps by brute force (looping through all the wards and seeing which ones intersect with our polygon) would be way to slow to do in real time Instead we can use a data structure called an R-tree[1] to build an index which provides a much, much faster way of looking up which polygons overlap another. We can build this tree in advance and save it somewhere, which means there’s a lot of computation we don’t need to do in real time. The R-tree returns a set of objects (ward IDs) which we can go and look up in our library of electoral wards. These wards will be the ones that might have some overlap with our custom polygon. Once we have this small set of wards which might overlap our ward, we can look at the size of the area of overlap (relative to the size of the whole ward) and multiply that by the known count of phones in that ward to get an approximation of the count of phones in the overlap area. Summing these approximations give an estimate for the whole area of the custom polygon. 1. https://en.wikipedia.org/wiki/R-tree
2021-03-18 23:02:32 +00:00
'70,000 to 100,000 phones',
]
),
(
[SKYE],
[
Update utils to do linear transformation of polygons Brings in https://github.com/alphagov/notifications-utils/pull/889/files At the moment, we are not doing any transformation of features before applying geometric algorithms to them. This is, in effect, assuming that the earth is flat. This new version of utils implements the transformation of our polygons to a Cartesian plane. In other words, it converts them from being defined in spherical degrees to metres. For the admin app this means we need to convert places where the code expects things to be measured in degrees to work in metres instead.
2021-08-03 18:46:30 +01:00
'An area of 2,000 square miles Will get the alert',
'An extra area of 600 square miles is Likely to get the alert',
'3,000 to 4,000 phones',
Estimate number of phones in an arbitrary polygon We want to know how many phones are in a user-supplied polygon, so we can show the impact of a broadcast, in the same way that we do when users pick areas from our library. We already know how many phones are in each electoral ward. But there are challenges with an arbitrary polygon: - where it does overlap a ward, the overlap could be partial - it could overlap more than one ward - finding out which wards it overlaps by brute force (looping through all the wards and seeing which ones intersect with our polygon) would be way to slow to do in real time Instead we can use a data structure called an R-tree[1] to build an index which provides a much, much faster way of looking up which polygons overlap another. We can build this tree in advance and save it somewhere, which means there’s a lot of computation we don’t need to do in real time. The R-tree returns a set of objects (ward IDs) which we can go and look up in our library of electoral wards. These wards will be the ones that might have some overlap with our custom polygon. Once we have this small set of wards which might overlap our ward, we can look at the size of the area of overlap (relative to the size of the whole ward) and multiply that by the known count of phones in that ward to get an approximation of the count of phones in the overlap area. Summing these approximations give an estimate for the whole area of the custom polygon. 1. https://en.wikipedia.org/wiki/R-tree
2021-03-18 23:02:32 +00:00
]
),
))
Display areas that aren’t in the library
2021-01-26 10:14:04 +00:00
def test_preview_broadcast_areas_page_with_custom_polygons(
mocker,
client_request,
service_one,
fake_uuid,
Estimate number of phones in an arbitrary polygon We want to know how many phones are in a user-supplied polygon, so we can show the impact of a broadcast, in the same way that we do when users pick areas from our library. We already know how many phones are in each electoral ward. But there are challenges with an arbitrary polygon: - where it does overlap a ward, the overlap could be partial - it could overlap more than one ward - finding out which wards it overlaps by brute force (looping through all the wards and seeing which ones intersect with our polygon) would be way to slow to do in real time Instead we can use a data structure called an R-tree[1] to build an index which provides a much, much faster way of looking up which polygons overlap another. We can build this tree in advance and save it somewhere, which means there’s a lot of computation we don’t need to do in real time. The R-tree returns a set of objects (ward IDs) which we can go and look up in our library of electoral wards. These wards will be the ones that might have some overlap with our custom polygon. Once we have this small set of wards which might overlap our ward, we can look at the size of the area of overlap (relative to the size of the whole ward) and multiply that by the known count of phones in that ward to get an approximation of the count of phones in the overlap area. Summing these approximations give an estimate for the whole area of the custom polygon. 1. https://en.wikipedia.org/wiki/R-tree
2021-03-18 23:02:32 +00:00
polygons,
expected_list_items,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
Display areas that aren’t in the library
2021-01-26 10:14:04 +00:00
):
service_one['permissions'] += ['broadcast']
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
template_id=fake_uuid,
created_by_id=fake_uuid,
service_id=SERVICE_ONE_ID,
status='draft',
Support custom broadcasts (without area IDs) Custom broadcasts created directly via the API app won't have area IDs since [1], where we started to distinguish between "names" (all broadcasts have these) and IDs (for broadcasts created in this app). We forgot to propagate the distinction into the code here. This code fixes the bug for all broadcasts created after [1]. Any custom broadcasts created before [1] will have their "ids" field set instead of "names" so we won't show anything for them. This seems reasonable as we don't support custom broadcasts yet. [1]: https://github.com/alphagov/notifications-api/pull/3312/commits/023a06d5fb4c20e6bf5a1c9e65b473cb376b2b6b
2021-09-06 10:02:01 +01:00
areas={
'names': ['Area one', 'Area two', 'Area three'],
'simple_polygons': polygons,
}
Display areas that aren’t in the library
2021-01-26 10:14:04 +00:00
),
)
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
Display areas that aren’t in the library
2021-01-26 10:14:04 +00:00
page = client_request.get(
'.preview_broadcast_areas',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
assert [
normalize_spaces(item.text)
for item in page.select('ul.area-list li.area-list-item')
] == [
Replace 'x' psuedo element with SVG The current link button for removing an area is created using a psuedo element with an 'x' as content. The inline box for the 'x' overlapped its parent. This is visible in high contrast mode, breaking the parent's border. Despite existing in CSS, the 'x' is also announced by screen readers, which is not what we want. This changes it to be an inline SVG with a role of image. It doesn't require as large an inline box so doesn't cause visual issues in high contrast modes. It also means we can set it's label similar to how you would an image's alt text, giving us control over what is announced by screen readers. This commit also includes some extra CSS, targeting high contrast modes, giving the link button the following when viewed in those modes: - a complete border so it is distinguishable from the list item - a focus style
2021-10-21 13:26:40 +01:00
'Area one Remove Area one', 'Area two Remove Area two', 'Area three Remove Area three',
Display areas that aren’t in the library
2021-01-26 10:14:04 +00:00
]
assert len(page.select('#area-list-map')) == 1
assert [
normalize_spaces(item.text)
Change map key items from list to paragraphs I recently found that there is a problem with the overuse of lists online for sequences of content that don't need to be in a list. I think that's what we're doing with our map key. The problem is large enough that browsers include heuristics to determine if lists should be presented as such to the accessibility API (and so to assistive tech' like screen readers). This thread contains more details: https://twitter.com/cookiecrook/status/1337226933822603270 Based on the metric described in the thread: 'If all of the styles that make it “list-like” have been removed, it’s no longer relevant to convey it as a list.' ...or 'if a sighted user doesn’t need to know it’s a list, why would a screen reader user need to know or want to know?' Based on that, I think the items in our map key should be paragraphs, not items in a list. Also, they read really well as sentences when announced by a screen reader, partly because of the extra (hidden) info @quis added to them. This also doesn't change their visual appearance.
2021-10-07 14:29:51 +01:00
for item in page.select('.area-list-key')
Estimate number of phones in an arbitrary polygon We want to know how many phones are in a user-supplied polygon, so we can show the impact of a broadcast, in the same way that we do when users pick areas from our library. We already know how many phones are in each electoral ward. But there are challenges with an arbitrary polygon: - where it does overlap a ward, the overlap could be partial - it could overlap more than one ward - finding out which wards it overlaps by brute force (looping through all the wards and seeing which ones intersect with our polygon) would be way to slow to do in real time Instead we can use a data structure called an R-tree[1] to build an index which provides a much, much faster way of looking up which polygons overlap another. We can build this tree in advance and save it somewhere, which means there’s a lot of computation we don’t need to do in real time. The R-tree returns a set of objects (ward IDs) which we can go and look up in our library of electoral wards. These wards will be the ones that might have some overlap with our custom polygon. Once we have this small set of wards which might overlap our ward, we can look at the size of the area of overlap (relative to the size of the whole ward) and multiply that by the known count of phones in that ward to get an approximation of the count of phones in the overlap area. Summing these approximations give an estimate for the whole area of the custom polygon. 1. https://en.wikipedia.org/wiki/R-tree
2021-03-18 23:02:32 +00:00
] == expected_list_items
Display areas that aren’t in the library
2021-01-26 10:14:04 +00:00
Stop saying "areas" when we mean "area_ids" "areas" normally means an instance of BroadcastArea or similar, so we should be more accurate to avoid confusion.
2021-08-26 10:42:20 +01:00
@pytest.mark.parametrize('area_ids, expected_list', (
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
([], [
'Countries',
Add another area to the library of test polygons
2021-04-28 13:50:27 +01:00
'Demo areas',
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
'Local authorities',
Add library of test areas This is a temporary addition so we can test out some functionality.
2021-02-19 10:43:24 +00:00
'Test areas',
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
]),
([
# Countries have no parent areas
'ctry19-E92000001',
'ctry19-S92000003',
], [
'Countries',
Add another area to the library of test polygons
2021-04-28 13:50:27 +01:00
'Demo areas',
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
'Local authorities',
Add library of test areas This is a temporary addition so we can test out some functionality.
2021-02-19 10:43:24 +00:00
'Test areas',
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
]),
([
# If you’ve chosen the whole of a county or unitary authority
# there’s no reason to also pick districts of it
'ctyua19-E10000013', # Gloucestershire, a county
'lad20-E06000052', # Cornwall, a unitary authority
], [
'Countries',
Add another area to the library of test polygons
2021-04-28 13:50:27 +01:00
'Demo areas',
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
'Local authorities',
Add library of test areas This is a temporary addition so we can test out some functionality.
2021-02-19 10:43:24 +00:00
'Test areas',
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
]),
([
'wd20-E05004299', # Pitville, in Cheltenham, in Gloucestershire
'wd20-E05004290', # Benhall and the Reddings, in Cheltenham, in Gloucestershire
'wd20-E05010951', # Abbeymead, in Gloucester, in Gloucestershire
'wd20-S13002775', # Shetland Central, in Shetland Isles
'lad20-E07000037', # High Peak, a district in Derbyshire
], [
'Cheltenham',
'Derbyshire',
'Gloucester',
'Gloucestershire',
'Shetland Islands',
# ---
'Countries',
Add another area to the library of test polygons
2021-04-28 13:50:27 +01:00
'Demo areas',
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
'Local authorities',
Add library of test areas This is a temporary addition so we can test out some functionality.
2021-02-19 10:43:24 +00:00
'Test areas',
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
]),
))
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
def test_choose_broadcast_library_page(
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
mocker,
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
client_request,
service_one,
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
fake_uuid,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
Stop saying "areas" when we mean "area_ids" "areas" normally means an instance of BroadcastArea or similar, so we should be more accurate to avoid confusion.
2021-08-26 10:42:20 +01:00
area_ids,
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
expected_list,
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
):
service_one['permissions'] += ['broadcast']
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
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
template_id=fake_uuid,
created_by_id=fake_uuid,
service_id=SERVICE_ONE_ID,
status='draft',
Stop saying "areas" when we mean "area_ids" "areas" normally means an instance of BroadcastArea or similar, so we should be more accurate to avoid confusion.
2021-08-26 10:42:20 +01:00
area_ids=area_ids,
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
),
)
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
Fix examples on choose broadcast library page It should be `.get_examples()` (a method) not `.examples` (a property) but Jinja swallows the error and prints nothing.
2020-07-08 16:02:16 +01:00
page = client_request.get(
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
'.choose_broadcast_library',
service_id=SERVICE_ONE_ID,
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=fake_uuid,
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
)
broadcast-areas: view test does not assert order the descriptions are liable to change esp for wards Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>
2020-08-10 13:04:03 +01:00
Remove the counties and unitary authorities library It’s been superceded by the ‘Local’ library (formerly ‘Electoral wards in the United Kingdom’). The latter is better because: - it’s covers all 4 nations, not just England and Wales - it has electoral wards as well as local authorities which group them, so there’s more flexibility when choosing an area to broadcast to
2020-08-13 12:27:55 +01:00
assert [
broadcast-areas: view test does not assert order the descriptions are liable to change esp for wards Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>
2020-08-10 13:04:03 +01:00
normalize_spaces(title.text)
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
for title in page.select('main a.govuk-link')
] == expected_list
broadcast-areas: view test does not assert order the descriptions are liable to change esp for wards Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>
2020-08-10 13:04:03 +01:00
Remove the counties and unitary authorities library It’s been superceded by the ‘Local’ library (formerly ‘Electoral wards in the United Kingdom’). The latter is better because: - it’s covers all 4 nations, not just England and Wales - it has electoral wards as well as local authorities which group them, so there’s more flexibility when choosing an area to broadcast to
2020-08-13 12:27:55 +01:00
assert normalize_spaces(page.select('.file-list-hint-large')[0].text) == (
generate library summary in python much simpler than sqlite. also remove oxford commas Co-authored-by: Chris Hill-Scott <me@quis.cc>
2020-09-09 17:35:17 +01:00
'England, Northern Ireland, Scotland and Wales'
broadcast-areas: examples are deterministic Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>
2020-08-11 11:33:27 +01:00
)
broadcast-areas: view test does not assert order the descriptions are liable to change esp for wards Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>
2020-08-10 13:04:03 +01:00
Fix examples on choose broadcast library page It should be `.get_examples()` (a method) not `.examples` (a property) but Jinja swallows the error and prints nothing.
2020-07-08 16:02:16 +01:00
assert page.select_one('a.file-list-filename-large.govuk-link')['href'] == url_for(
'.choose_broadcast_area',
service_id=SERVICE_ONE_ID,
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=fake_uuid,
Remove the counties and unitary authorities library It’s been superceded by the ‘Local’ library (formerly ‘Electoral wards in the United Kingdom’). The latter is better because: - it’s covers all 4 nations, not just England and Wales - it has electoral wards as well as local authorities which group them, so there’s more flexibility when choosing an area to broadcast to
2020-08-13 12:27:55 +01:00
library_slug='ctry19',
Fix examples on choose broadcast library page It should be `.get_examples()` (a method) not `.examples` (a property) but Jinja swallows the error and prints nothing.
2020-07-08 16:02:16 +01:00
)
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +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
def test_suggested_area_has_correct_link(
mocker,
client_request,
service_one,
fake_uuid,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
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
):
service_one['permissions'] += ['broadcast']
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
template_id=fake_uuid,
created_by_id=fake_uuid,
service_id=SERVICE_ONE_ID,
status='draft',
Stop saying "areas" when we mean "area_ids" "areas" normally means an instance of BroadcastArea or similar, so we should be more accurate to avoid confusion.
2021-08-26 10:42:20 +01:00
area_ids=[
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
'wd20-E05004299', # Pitville, a ward of Cheltenham
],
),
)
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
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
page = client_request.get(
'.choose_broadcast_library',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
link = page.select_one('main a.govuk-link')
assert link.text == 'Cheltenham'
assert link['href'] == url_for(
'main.choose_broadcast_sub_area',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
library_slug='wd20-lad20-ctyua19',
area_slug='lad20-E07000078',
)
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
def test_choose_broadcast_area_page(
client_request,
service_one,
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
mock_get_draft_broadcast_message,
fake_uuid,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
):
service_one['permissions'] += ['broadcast']
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
page = client_request.get(
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
'.choose_broadcast_area',
service_id=SERVICE_ONE_ID,
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=fake_uuid,
Rename electoral wards to local areas We’ve observed people using ‘national’ and ‘local’ during user research. It has less tongue-twisting ambiguity than county vs country. But we think that maybe just getting rid of ‘counties’ is enough to disambiguate them. So this commit just takes the ‘local’ concept. This commit also gives the libraries and areas new IDs, which means if we want to rename them in the future it won’t be a breaking change.
2020-08-13 12:25:22 +01:00
library_slug='ctry19',
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
)
Add singular descriptions for libraries This lets us write nice interface copy like ‘Choose a local authority from the local authorities library’.
2020-08-13 17:33:58 +01:00
assert normalize_spaces(page.select_one('h1').text) == (
'Choose countries'
)
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
assert [
(
choice.select_one('input')['value'],
normalize_spaces(choice.select_one('label').text),
)
for choice in page.select('form[method=post] .govuk-checkboxes__item')
] == [
Rename electoral wards to local areas We’ve observed people using ‘national’ and ‘local’ during user research. It has less tongue-twisting ambiguity than county vs country. But we think that maybe just getting rid of ‘counties’ is enough to disambiguate them. So this commit just takes the ‘local’ concept. This commit also gives the libraries and areas new IDs, which means if we want to rename them in the future it won’t be a breaking change.
2020-08-13 12:25:22 +01:00
('ctry19-E92000001', 'England'),
('ctry19-N92000002', 'Northern Ireland'),
('ctry19-S92000003', 'Scotland'),
('ctry19-W92000004', 'Wales'),
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
]
def test_choose_broadcast_area_page_for_area_with_sub_areas(
client_request,
service_one,
mock_get_draft_broadcast_message,
fake_uuid,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
):
service_one['permissions'] += ['broadcast']
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
page = client_request.get(
'.choose_broadcast_area',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
add counties page What was previously ward -> local authority is now a ward -> local authority -> county. County only covers rural counties and not metropolitan boroughs and other unitary authorities. Previously, there was a page full of local authorities (unitary authorities and districts), and each one of those would have a list of electoral wards. However, now there are counties that contain a list of districts - so this needs a new page - a checkbox for "select the county" and then a list of links to district pages. If you want to select multiple districts, you'll need to go into each one of those sub-sections in turn and click select all. Needed to tweak the query to retrieve the list of areas in a list for a library. Previously, it just returned anything at top level (ie: didn't have a parent). However, rural districts now have parents (the rural counties themselves). So the query now returns "everything that isn't a leaf node", or in more specific terms, everything that has at least other row referring to it as a parent. So no electoral wards, since they dont have any children, but yes to districts and counties.
2020-09-04 15:22:32 +01:00
library_slug='wd20-lad20-ctyua19',
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
)
Add singular descriptions for libraries This lets us write nice interface copy like ‘Choose a local authority from the local authorities library’.
2020-08-13 17:33:58 +01:00
assert normalize_spaces(page.select_one('h1').text) == (
'Choose a local authority'
)
Fix live search when selecting broadcast sub areas It was targeting the wrong element because it hadn’t been updated to reflect that we’re now using the Design System checkboxes.
2020-08-12 16:33:00 +01:00
live_search = page.select_one("[data-module=live-search]")
assert live_search['data-targets'] == '.file-list-item'
assert live_search.select_one('input')['type'] == 'search'
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
partial_url_for = partial(
url_for,
'main.choose_broadcast_sub_area',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
add counties page What was previously ward -> local authority is now a ward -> local authority -> county. County only covers rural counties and not metropolitan boroughs and other unitary authorities. Previously, there was a page full of local authorities (unitary authorities and districts), and each one of those would have a list of electoral wards. However, now there are counties that contain a list of districts - so this needs a new page - a checkbox for "select the county" and then a list of links to district pages. If you want to select multiple districts, you'll need to go into each one of those sub-sections in turn and click select all. Needed to tweak the query to retrieve the list of areas in a list for a library. Previously, it just returned anything at top level (ie: didn't have a parent). However, rural districts now have parents (the rural counties themselves). So the query now returns "everything that isn't a leaf node", or in more specific terms, everything that has at least other row referring to it as a parent. So no electoral wards, since they dont have any children, but yes to districts and counties.
2020-09-04 15:22:32 +01:00
library_slug='wd20-lad20-ctyua19',
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
)
choices = [
(
choice.select_one('a.file-list-filename-large')['href'],
normalize_spaces(choice.text),
)
for choice in page.select('.file-list-item')
]
make tests pass (acknowledge that code is wrong) i really don't want to fix this right now but that total isn't quite right
2020-09-07 21:57:05 +01:00
assert len(choices) == 394
add back links previously the back link went to choosing a library. Now, if you view a district from a county, go back to the county page. Otherwise, go back to the top level of the library.
2020-09-15 13:53:38 +01:00
assert choices[0] == (partial_url_for(area_slug='lad20-S12000033'), 'Aberdeen City',)
# note: we don't populate prev_area_slug query param, so the back link will come here rather than to a county page,
# even though ashford belongs to kent
assert choices[12] == (partial_url_for(area_slug='lad20-E07000105'), 'Ashford',)
assert choices[-1] == (partial_url_for(area_slug='lad20-E06000014'), 'York',)
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
add counties page What was previously ward -> local authority is now a ward -> local authority -> county. County only covers rural counties and not metropolitan boroughs and other unitary authorities. Previously, there was a page full of local authorities (unitary authorities and districts), and each one of those would have a list of electoral wards. However, now there are counties that contain a list of districts - so this needs a new page - a checkbox for "select the county" and then a list of links to district pages. If you want to select multiple districts, you'll need to go into each one of those sub-sections in turn and click select all. Needed to tweak the query to retrieve the list of areas in a list for a library. Previously, it just returned anything at top level (ie: didn't have a parent). However, rural districts now have parents (the rural counties themselves). So the query now returns "everything that isn't a leaf node", or in more specific terms, everything that has at least other row referring to it as a parent. So no electoral wards, since they dont have any children, but yes to districts and counties.
2020-09-04 15:22:32 +01:00
def test_choose_broadcast_sub_area_page_for_district_shows_checkboxes_for_wards(
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
client_request,
service_one,
mock_get_draft_broadcast_message,
fake_uuid,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
):
service_one['permissions'] += ['broadcast']
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
page = client_request.get(
'main.choose_broadcast_sub_area',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
add counties page What was previously ward -> local authority is now a ward -> local authority -> county. County only covers rural counties and not metropolitan boroughs and other unitary authorities. Previously, there was a page full of local authorities (unitary authorities and districts), and each one of those would have a list of electoral wards. However, now there are counties that contain a list of districts - so this needs a new page - a checkbox for "select the county" and then a list of links to district pages. If you want to select multiple districts, you'll need to go into each one of those sub-sections in turn and click select all. Needed to tweak the query to retrieve the list of areas in a list for a library. Previously, it just returned anything at top level (ie: didn't have a parent). However, rural districts now have parents (the rural counties themselves). So the query now returns "everything that isn't a leaf node", or in more specific terms, everything that has at least other row referring to it as a parent. So no electoral wards, since they dont have any children, but yes to districts and counties.
2020-09-04 15:22:32 +01:00
library_slug='wd20-lad20-ctyua19',
Rename electoral wards to local areas We’ve observed people using ‘national’ and ‘local’ during user research. It has less tongue-twisting ambiguity than county vs country. But we think that maybe just getting rid of ‘counties’ is enough to disambiguate them. So this commit just takes the ‘local’ concept. This commit also gives the libraries and areas new IDs, which means if we want to rename them in the future it won’t be a breaking change.
2020-08-13 12:25:22 +01:00
area_slug='lad20-S12000033',
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
)
assert normalize_spaces(page.select_one('h1').text) == (
'Choose an area of Aberdeen City'
)
Fix live search when selecting broadcast sub areas It was targeting the wrong element because it hadn’t been updated to reflect that we’re now using the Design System checkboxes.
2020-08-12 16:33:00 +01:00
live_search = page.select_one("[data-module=live-search]")
Don’t filter ‘All of’ choice with live search Because the ‘All of’ choice appears above the search field, it shouldn’t be filtered by the search field. We can fix this by wrapping the sub-areas in a `<div>` and make the selector more specific.
2020-08-26 10:59:29 +01:00
assert live_search['data-targets'] == '#sub-areas .govuk-checkboxes__item'
Fix live search when selecting broadcast sub areas It was targeting the wrong element because it hadn’t been updated to reflect that we’re now using the Design System checkboxes.
2020-08-12 16:33:00 +01:00
assert live_search.select_one('input')['type'] == 'search'
Don’t filter ‘All of’ choice with live search Because the ‘All of’ choice appears above the search field, it shouldn’t be filtered by the search field. We can fix this by wrapping the sub-areas in a `<div>` and make the selector more specific.
2020-08-26 10:59:29 +01:00
all_choices = [
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
(
choice.select_one('input')['value'],
normalize_spaces(choice.select_one('label').text),
)
for choice in page.select('form[method=post] .govuk-checkboxes__item')
]
Don’t filter ‘All of’ choice with live search Because the ‘All of’ choice appears above the search field, it shouldn’t be filtered by the search field. We can fix this by wrapping the sub-areas in a `<div>` and make the selector more specific.
2020-08-26 10:59:29 +01:00
sub_choices = [
(
choice.select_one('input')['value'],
normalize_spaces(choice.select_one('label').text),
)
for choice in page.select('form[method=post] #sub-areas .govuk-checkboxes__item')
]
assert all_choices[:3] == [
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
('y', 'All of Aberdeen City'),
Rename electoral wards to local areas We’ve observed people using ‘national’ and ‘local’ during user research. It has less tongue-twisting ambiguity than county vs country. But we think that maybe just getting rid of ‘counties’ is enough to disambiguate them. So this commit just takes the ‘local’ concept. This commit also gives the libraries and areas new IDs, which means if we want to rename them in the future it won’t be a breaking change.
2020-08-13 12:25:22 +01:00
('wd20-S13002845', 'Airyhall/Broomhill/Garthdee'),
('wd20-S13002836', 'Bridge of Don'),
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
]
Don’t filter ‘All of’ choice with live search Because the ‘All of’ choice appears above the search field, it shouldn’t be filtered by the search field. We can fix this by wrapping the sub-areas in a `<div>` and make the selector more specific.
2020-08-26 10:59:29 +01:00
assert sub_choices[:3] == [
('wd20-S13002845', 'Airyhall/Broomhill/Garthdee'),
('wd20-S13002836', 'Bridge of Don'),
('wd20-S13002835', 'Dyce/Bucksburn/Danestone'),
]
assert all_choices[-1:] == sub_choices[-1:] == [
Rename electoral wards to local areas We’ve observed people using ‘national’ and ‘local’ during user research. It has less tongue-twisting ambiguity than county vs country. But we think that maybe just getting rid of ‘counties’ is enough to disambiguate them. So this commit just takes the ‘local’ concept. This commit also gives the libraries and areas new IDs, which means if we want to rename them in the future it won’t be a breaking change.
2020-08-13 12:25:22 +01:00
('wd20-S13002846', 'Torry/Ferryhill'),
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
]
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
add back links previously the back link went to choosing a library. Now, if you view a district from a county, go back to the county page. Otherwise, go back to the top level of the library.
2020-09-15 13:53:38 +01:00
@pytest.mark.parametrize('prev_area_slug, expected_back_link_url, expected_back_link_extra_kwargs', [
(
'ctyua19-E10000016',
'main.choose_broadcast_sub_area',
{
'area_slug': 'ctyua19-E10000016' # Kent
}
),
(
None,
'.choose_broadcast_area',
{}
)
])
def test_choose_broadcast_sub_area_page_for_district_has_back_link(
client_request,
service_one,
mock_get_draft_broadcast_message,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
add back links previously the back link went to choosing a library. Now, if you view a district from a county, go back to the county page. Otherwise, go back to the top level of the library.
2020-09-15 13:53:38 +01:00
prev_area_slug,
expected_back_link_url,
expected_back_link_extra_kwargs
):
service_one['permissions'] += ['broadcast']
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
add back links previously the back link went to choosing a library. Now, if you view a district from a county, go back to the county page. Otherwise, go back to the top level of the library.
2020-09-15 13:53:38 +01:00
page = client_request.get(
'main.choose_broadcast_sub_area',
service_id=SERVICE_ONE_ID,
broadcast_message_id=str(uuid.UUID(int=0)),
library_slug='wd20-lad20-ctyua19',
area_slug='lad20-E07000105', # Ashford
prev_area_slug=prev_area_slug,
)
assert normalize_spaces(page.select_one('h1').text) == (
'Choose an area of Ashford'
)
back_link = page.select_one('.govuk-back-link')
assert back_link['href'] == url_for(
expected_back_link_url,
service_id=SERVICE_ONE_ID,
broadcast_message_id=str(uuid.UUID(int=0)),
library_slug='wd20-lad20-ctyua19',
**expected_back_link_extra_kwargs
)
add counties page What was previously ward -> local authority is now a ward -> local authority -> county. County only covers rural counties and not metropolitan boroughs and other unitary authorities. Previously, there was a page full of local authorities (unitary authorities and districts), and each one of those would have a list of electoral wards. However, now there are counties that contain a list of districts - so this needs a new page - a checkbox for "select the county" and then a list of links to district pages. If you want to select multiple districts, you'll need to go into each one of those sub-sections in turn and click select all. Needed to tweak the query to retrieve the list of areas in a list for a library. Previously, it just returned anything at top level (ie: didn't have a parent). However, rural districts now have parents (the rural counties themselves). So the query now returns "everything that isn't a leaf node", or in more specific terms, everything that has at least other row referring to it as a parent. So no electoral wards, since they dont have any children, but yes to districts and counties.
2020-09-04 15:22:32 +01:00
def test_choose_broadcast_sub_area_page_for_county_shows_links_for_districts(
client_request,
service_one,
mock_get_draft_broadcast_message,
fake_uuid,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
add counties page What was previously ward -> local authority is now a ward -> local authority -> county. County only covers rural counties and not metropolitan boroughs and other unitary authorities. Previously, there was a page full of local authorities (unitary authorities and districts), and each one of those would have a list of electoral wards. However, now there are counties that contain a list of districts - so this needs a new page - a checkbox for "select the county" and then a list of links to district pages. If you want to select multiple districts, you'll need to go into each one of those sub-sections in turn and click select all. Needed to tweak the query to retrieve the list of areas in a list for a library. Previously, it just returned anything at top level (ie: didn't have a parent). However, rural districts now have parents (the rural counties themselves). So the query now returns "everything that isn't a leaf node", or in more specific terms, everything that has at least other row referring to it as a parent. So no electoral wards, since they dont have any children, but yes to districts and counties.
2020-09-04 15:22:32 +01:00
):
service_one['permissions'] += ['broadcast']
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
add counties page What was previously ward -> local authority is now a ward -> local authority -> county. County only covers rural counties and not metropolitan boroughs and other unitary authorities. Previously, there was a page full of local authorities (unitary authorities and districts), and each one of those would have a list of electoral wards. However, now there are counties that contain a list of districts - so this needs a new page - a checkbox for "select the county" and then a list of links to district pages. If you want to select multiple districts, you'll need to go into each one of those sub-sections in turn and click select all. Needed to tweak the query to retrieve the list of areas in a list for a library. Previously, it just returned anything at top level (ie: didn't have a parent). However, rural districts now have parents (the rural counties themselves). So the query now returns "everything that isn't a leaf node", or in more specific terms, everything that has at least other row referring to it as a parent. So no electoral wards, since they dont have any children, but yes to districts and counties.
2020-09-04 15:22:32 +01:00
page = client_request.get(
'main.choose_broadcast_sub_area',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
library_slug='wd20-lad20-ctyua19',
area_slug='ctyua19-E10000016', # Kent
)
assert normalize_spaces(page.select_one('h1').text) == (
'Choose an area of Kent'
)
live_search = page.select_one("[data-module=live-search]")
assert live_search['data-targets'] == '.file-list-item'
assert live_search.select_one('input')['type'] == 'search'
all_choices_checkbox = [
(
choice.select_one('input')['value'],
normalize_spaces(choice.select_one('label').text),
)
for choice in page.select('form[method=post] .govuk-checkboxes__item')
]
districts = [
(
district['href'],
district.text,
)
for district in page.select('form[method=post] a')
]
assert all_choices_checkbox == [
('y', 'All of Kent'),
]
assert len(districts) == 12
assert districts[0][0] == url_for(
'main.choose_broadcast_sub_area',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
library_slug='wd20-lad20-ctyua19',
add back links previously the back link went to choosing a library. Now, if you view a district from a county, go back to the county page. Otherwise, go back to the top level of the library.
2020-09-15 13:53:38 +01:00
area_slug='lad20-E07000105',
prev_area_slug='ctyua19-E10000016', # Kent
add counties page What was previously ward -> local authority is now a ward -> local authority -> county. County only covers rural counties and not metropolitan boroughs and other unitary authorities. Previously, there was a page full of local authorities (unitary authorities and districts), and each one of those would have a list of electoral wards. However, now there are counties that contain a list of districts - so this needs a new page - a checkbox for "select the county" and then a list of links to district pages. If you want to select multiple districts, you'll need to go into each one of those sub-sections in turn and click select all. Needed to tweak the query to retrieve the list of areas in a list for a library. Previously, it just returned anything at top level (ie: didn't have a parent). However, rural districts now have parents (the rural counties themselves). So the query now returns "everything that isn't a leaf node", or in more specific terms, everything that has at least other row referring to it as a parent. So no electoral wards, since they dont have any children, but yes to districts and counties.
2020-09-04 15:22:32 +01:00
)
assert districts[0][1] == 'Ashford'
assert districts[-1][0] == url_for(
'main.choose_broadcast_sub_area',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
library_slug='wd20-lad20-ctyua19',
add back links previously the back link went to choosing a library. Now, if you view a district from a county, go back to the county page. Otherwise, go back to the top level of the library.
2020-09-15 13:53:38 +01:00
area_slug='lad20-E07000116',
prev_area_slug='ctyua19-E10000016', # Kent
add counties page What was previously ward -> local authority is now a ward -> local authority -> county. County only covers rural counties and not metropolitan boroughs and other unitary authorities. Previously, there was a page full of local authorities (unitary authorities and districts), and each one of those would have a list of electoral wards. However, now there are counties that contain a list of districts - so this needs a new page - a checkbox for "select the county" and then a list of links to district pages. If you want to select multiple districts, you'll need to go into each one of those sub-sections in turn and click select all. Needed to tweak the query to retrieve the list of areas in a list for a library. Previously, it just returned anything at top level (ie: didn't have a parent). However, rural districts now have parents (the rural counties themselves). So the query now returns "everything that isn't a leaf node", or in more specific terms, everything that has at least other row referring to it as a parent. So no electoral wards, since they dont have any children, but yes to districts and counties.
2020-09-04 15:22:32 +01:00
)
assert districts[-1][1] == 'Tunbridge Wells'
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 test_add_broadcast_area(
client_request,
service_one,
mock_get_draft_broadcast_message,
mock_update_broadcast_message,
fake_uuid,
Allow users with new broadcast permissions access to routes Added two new permissions - `create_broadcasts` and `approve_broadcasts`. These new permissions get added to the `has_permissions` decorator of the broadcast routes to allow the routes to be accessed with either the old permissions on the new ones while we switch over. We were using the `send_messages` permission for the broadcast routes. By having two new permissions we can allow a more granular control of these routes.
2021-06-17 18:03:58 +01:00
mocker,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
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_one['permissions'] += ['broadcast']
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
polygon_class = namedtuple("polygon_class", ["as_coordinate_pairs_lat_long"])
coordinates = [[50.1, 0.1], [50.2, 0.2], [50.3, 0.2]]
polygons = polygon_class(as_coordinate_pairs_lat_long=coordinates)
Refactor `get_simple_polygons` method for reuse This means we: - don’t need to pass the areas around as an argument - keep all the complexity of combining polygons from different areas in one method
2021-09-01 20:14:14 +01:00
mock_get_polygons_from_areas = mocker.patch(
'app.models.broadcast_message.BroadcastMessage.get_polygons_from_areas',
return_value=polygons,
)
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
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
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
client_request.post(
'.choose_broadcast_area',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
Rename electoral wards to local areas We’ve observed people using ‘national’ and ‘local’ during user research. It has less tongue-twisting ambiguity than county vs country. But we think that maybe just getting rid of ‘counties’ is enough to disambiguate them. So this commit just takes the ‘local’ concept. This commit also gives the libraries and areas new IDs, which means if we want to rename them in the future it won’t be a breaking change.
2020-08-13 12:25:22 +01:00
library_slug='ctry19',
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
_data={
Rename electoral wards to local areas We’ve observed people using ‘national’ and ‘local’ during user research. It has less tongue-twisting ambiguity than county vs country. But we think that maybe just getting rid of ‘counties’ is enough to disambiguate them. So this commit just takes the ‘local’ concept. This commit also gives the libraries and areas new IDs, which means if we want to rename them in the future it won’t be a breaking change.
2020-08-13 12:25:22 +01:00
'areas': ['ctry19-E92000001', 'ctry19-W92000004']
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 `get_simple_polygons` method for reuse This means we: - don’t need to pass the areas around as an argument - keep all the complexity of combining polygons from different areas in one method
2021-09-01 20:14:14 +01:00
mock_get_polygons_from_areas.assert_called_once_with(area_attribute='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
mock_update_broadcast_message.assert_called_once_with(
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
data={
Complete migration to new "areas" API format Depends on: https://github.com/alphagov/notifications-api/pull/3314 Previously: - We introduced a new "areas_2" API field that's can populate the "areas" column in the same way. - We updated the Admin app to use the new field, so that the old "areas" and "simple_polygons" API fields are unused. - We repurposed the unused "areas" API field to use the new "areas_2" format. This PR: - We can switch the Admin app back to the "areas" field, but in the new format. Future PRs: - Remove support for the unused "areas_2" field (migration complete)
2021-08-27 14:32:56 +01:00
'areas': {
Switch to using temporary "areas_2" API field Depends on: https://github.com/alphagov/notifications-api/pull/3312 This is part of a multi-stage migration where we want to repurpose the "areas" field in the existing API to something like "areas_2".
2021-08-25 17:17:05 +01:00
'ids': ['ctry19-E92000001', 'ctry19-S92000003', 'ctry19-W92000004'],
Include area names in data we send to API These will be used as a fallback for display in gov.uk/alerts. It also helps to have them in the DB to aid in quickly identifying where an alert was sent, which is hard from the IDs. We will look at backfilling names for past alerts in future work.
2021-08-26 11:55:00 +01:00
'names': ['England', 'Scotland', 'Wales'],
Start sending aggregate area names to API The aggregate names don't need to be sorted, but it helps to do this for the tests, since the implementation of sets may not be stable between machines and lead to sporadic test failures. I did also toy with sorting granular area names so they have a similar ordering, but this would take them out-of-order with IDs and really the important thing is that the ordering is stable.
2021-08-27 14:58:45 +01:00
'aggregate_names': ['England', 'Scotland', 'Wales'],
Switch to using temporary "areas_2" API field Depends on: https://github.com/alphagov/notifications-api/pull/3312 This is part of a multi-stage migration where we want to repurpose the "areas" field in the existing API to something like "areas_2".
2021-08-25 17:17:05 +01:00
'simple_polygons': coordinates
}
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
},
)
Include area names in data we send to API These will be used as a fallback for display in gov.uk/alerts. It also helps to have them in the DB to aid in quickly identifying where an alert was sent, which is hard from the IDs. We will look at backfilling names for past alerts in future work.
2021-08-26 11:55:00 +01:00
@pytest.mark.parametrize('post_data, expected_data', (
(
{
'select_all': 'y', 'areas': ['wd20-S13002845']
},
{
# wd20-S13002845 is ignored because the user chose ‘Select all…’
Start sending aggregate area names to API The aggregate names don't need to be sorted, but it helps to do this for the tests, since the implementation of sets may not be stable between machines and lead to sporadic test failures. I did also toy with sorting granular area names so they have a similar ordering, but this would take them out-of-order with IDs and really the important thing is that the ordering is stable.
2021-08-27 14:58:45 +01:00
'ids': ['lad20-S12000033'],
'names': ['Aberdeen City'],
'aggregate_names': ['Aberdeen City']
Include area names in data we send to API These will be used as a fallback for display in gov.uk/alerts. It also helps to have them in the DB to aid in quickly identifying where an alert was sent, which is hard from the IDs. We will look at backfilling names for past alerts in future work.
2021-08-26 11:55:00 +01:00
}
),
(
{
'areas': ['wd20-S13002845', 'wd20-S13002836']
},
{
'ids': ['wd20-S13002845', 'wd20-S13002836'],
'names': ['Bridge of Don', 'Airyhall/Broomhill/Garthdee'],
Start sending aggregate area names to API The aggregate names don't need to be sorted, but it helps to do this for the tests, since the implementation of sets may not be stable between machines and lead to sporadic test failures. I did also toy with sorting granular area names so they have a similar ordering, but this would take them out-of-order with IDs and really the important thing is that the ordering is stable.
2021-08-27 14:58:45 +01:00
'aggregate_names': ['Aberdeen City'],
Include area names in data we send to API These will be used as a fallback for display in gov.uk/alerts. It also helps to have them in the DB to aid in quickly identifying where an alert was sent, which is hard from the IDs. We will look at backfilling names for past alerts in future work.
2021-08-26 11:55:00 +01:00
}
),
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
))
add counties page What was previously ward -> local authority is now a ward -> local authority -> county. County only covers rural counties and not metropolitan boroughs and other unitary authorities. Previously, there was a page full of local authorities (unitary authorities and districts), and each one of those would have a list of electoral wards. However, now there are counties that contain a list of districts - so this needs a new page - a checkbox for "select the county" and then a list of links to district pages. If you want to select multiple districts, you'll need to go into each one of those sub-sections in turn and click select all. Needed to tweak the query to retrieve the list of areas in a list for a library. Previously, it just returned anything at top level (ie: didn't have a parent). However, rural districts now have parents (the rural counties themselves). So the query now returns "everything that isn't a leaf node", or in more specific terms, everything that has at least other row referring to it as a parent. So no electoral wards, since they dont have any children, but yes to districts and counties.
2020-09-04 15:22:32 +01:00
def test_add_broadcast_sub_area_district_view(
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
client_request,
service_one,
mock_get_draft_broadcast_message,
mock_update_broadcast_message,
fake_uuid,
post_data,
Include area names in data we send to API These will be used as a fallback for display in gov.uk/alerts. It also helps to have them in the DB to aid in quickly identifying where an alert was sent, which is hard from the IDs. We will look at backfilling names for past alerts in future work.
2021-08-26 11:55:00 +01:00
expected_data,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
mocker,
active_user_create_broadcasts_permission,
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
):
service_one['permissions'] += ['broadcast']
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
polygon_class = namedtuple("polygon_class", ["as_coordinate_pairs_lat_long"])
coordinates = [[50.1, 0.1], [50.2, 0.2], [50.3, 0.2]]
polygons = polygon_class(as_coordinate_pairs_lat_long=coordinates)
Refactor `get_simple_polygons` method for reuse This means we: - don’t need to pass the areas around as an argument - keep all the complexity of combining polygons from different areas in one method
2021-09-01 20:14:14 +01:00
mock_get_polygons_from_areas = mocker.patch(
'app.models.broadcast_message.BroadcastMessage.get_polygons_from_areas',
return_value=polygons,
)
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
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
client_request.post(
'.choose_broadcast_sub_area',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
add counties page What was previously ward -> local authority is now a ward -> local authority -> county. County only covers rural counties and not metropolitan boroughs and other unitary authorities. Previously, there was a page full of local authorities (unitary authorities and districts), and each one of those would have a list of electoral wards. However, now there are counties that contain a list of districts - so this needs a new page - a checkbox for "select the county" and then a list of links to district pages. If you want to select multiple districts, you'll need to go into each one of those sub-sections in turn and click select all. Needed to tweak the query to retrieve the list of areas in a list for a library. Previously, it just returned anything at top level (ie: didn't have a parent). However, rural districts now have parents (the rural counties themselves). So the query now returns "everything that isn't a leaf node", or in more specific terms, everything that has at least other row referring to it as a parent. So no electoral wards, since they dont have any children, but yes to districts and counties.
2020-09-04 15:22:32 +01:00
library_slug='wd20-lad20-ctyua19',
Rename electoral wards to local areas We’ve observed people using ‘national’ and ‘local’ during user research. It has less tongue-twisting ambiguity than county vs country. But we think that maybe just getting rid of ‘counties’ is enough to disambiguate them. So this commit just takes the ‘local’ concept. This commit also gives the libraries and areas new IDs, which means if we want to rename them in the future it won’t be a breaking change.
2020-08-13 12:25:22 +01:00
area_slug='lad20-S12000033',
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
_data=post_data,
)
Include area names in data we send to API These will be used as a fallback for display in gov.uk/alerts. It also helps to have them in the DB to aid in quickly identifying where an alert was sent, which is hard from the IDs. We will look at backfilling names for past alerts in future work.
2021-08-26 11:55:00 +01:00
# These two areas are on the broadcast already
expected_data['ids'] = ['ctry19-E92000001', 'ctry19-S92000003'] + expected_data['ids']
expected_data['names'] = ['England', 'Scotland'] + expected_data['names']
Start sending aggregate area names to API The aggregate names don't need to be sorted, but it helps to do this for the tests, since the implementation of sets may not be stable between machines and lead to sporadic test failures. I did also toy with sorting granular area names so they have a similar ordering, but this would take them out-of-order with IDs and really the important thing is that the ordering is stable.
2021-08-27 14:58:45 +01:00
expected_data['aggregate_names'] = sorted(['England', 'Scotland'] + expected_data['aggregate_names'])
Include area names in data we send to API These will be used as a fallback for display in gov.uk/alerts. It also helps to have them in the DB to aid in quickly identifying where an alert was sent, which is hard from the IDs. We will look at backfilling names for past alerts in future work.
2021-08-26 11:55:00 +01:00
Refactor `get_simple_polygons` method for reuse This means we: - don’t need to pass the areas around as an argument - keep all the complexity of combining polygons from different areas in one method
2021-09-01 20:14:14 +01:00
mock_get_polygons_from_areas.assert_called_once_with(area_attribute='simple_polygons')
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
mock_update_broadcast_message.assert_called_once_with(
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
data={
Complete migration to new "areas" API format Depends on: https://github.com/alphagov/notifications-api/pull/3314 Previously: - We introduced a new "areas_2" API field that's can populate the "areas" column in the same way. - We updated the Admin app to use the new field, so that the old "areas" and "simple_polygons" API fields are unused. - We repurposed the unused "areas" API field to use the new "areas_2" format. This PR: - We can switch the Admin app back to the "areas" field, but in the new format. Future PRs: - Remove support for the unused "areas_2" field (migration complete)
2021-08-27 14:32:56 +01:00
'areas': {
Switch to using temporary "areas_2" API field Depends on: https://github.com/alphagov/notifications-api/pull/3312 This is part of a multi-stage migration where we want to repurpose the "areas" field in the existing API to something like "areas_2".
2021-08-25 17:17:05 +01:00
'simple_polygons': coordinates,
Include area names in data we send to API These will be used as a fallback for display in gov.uk/alerts. It also helps to have them in the DB to aid in quickly identifying where an alert was sent, which is hard from the IDs. We will look at backfilling names for past alerts in future work.
2021-08-26 11:55:00 +01:00
**expected_data,
Switch to using temporary "areas_2" API field Depends on: https://github.com/alphagov/notifications-api/pull/3312 This is part of a multi-stage migration where we want to repurpose the "areas" field in the existing API to something like "areas_2".
2021-08-25 17:17:05 +01:00
}
Let users select electoral wards of local authorities If a library has groups, we should show a link instead of selecting the group directly. Then we can give the user the choice of selecting the whole of that group, or specific areas within the group. For now the only libraries we have with groups are local authorities, which group electoral wards.
2020-07-31 16:20:37 +01:00
},
)
add counties page What was previously ward -> local authority is now a ward -> local authority -> county. County only covers rural counties and not metropolitan boroughs and other unitary authorities. Previously, there was a page full of local authorities (unitary authorities and districts), and each one of those would have a list of electoral wards. However, now there are counties that contain a list of districts - so this needs a new page - a checkbox for "select the county" and then a list of links to district pages. If you want to select multiple districts, you'll need to go into each one of those sub-sections in turn and click select all. Needed to tweak the query to retrieve the list of areas in a list for a library. Previously, it just returned anything at top level (ie: didn't have a parent). However, rural districts now have parents (the rural counties themselves). So the query now returns "everything that isn't a leaf node", or in more specific terms, everything that has at least other row referring to it as a parent. So no electoral wards, since they dont have any children, but yes to districts and counties.
2020-09-04 15:22:32 +01:00
def test_add_broadcast_sub_area_county_view(
client_request,
service_one,
mock_get_draft_broadcast_message,
mock_update_broadcast_message,
fake_uuid,
mocker,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
add counties page What was previously ward -> local authority is now a ward -> local authority -> county. County only covers rural counties and not metropolitan boroughs and other unitary authorities. Previously, there was a page full of local authorities (unitary authorities and districts), and each one of those would have a list of electoral wards. However, now there are counties that contain a list of districts - so this needs a new page - a checkbox for "select the county" and then a list of links to district pages. If you want to select multiple districts, you'll need to go into each one of those sub-sections in turn and click select all. Needed to tweak the query to retrieve the list of areas in a list for a library. Previously, it just returned anything at top level (ie: didn't have a parent). However, rural districts now have parents (the rural counties themselves). So the query now returns "everything that isn't a leaf node", or in more specific terms, everything that has at least other row referring to it as a parent. So no electoral wards, since they dont have any children, but yes to districts and counties.
2020-09-04 15:22:32 +01:00
):
service_one['permissions'] += ['broadcast']
polygon_class = namedtuple("polygon_class", ["as_coordinate_pairs_lat_long"])
coordinates = [[50.1, 0.1], [50.2, 0.2], [50.3, 0.2]]
polygons = polygon_class(as_coordinate_pairs_lat_long=coordinates)
Refactor `get_simple_polygons` method for reuse This means we: - don’t need to pass the areas around as an argument - keep all the complexity of combining polygons from different areas in one method
2021-09-01 20:14:14 +01:00
mock_get_polygons_from_areas = mocker.patch(
'app.models.broadcast_message.BroadcastMessage.get_polygons_from_areas',
return_value=polygons,
)
add counties page What was previously ward -> local authority is now a ward -> local authority -> county. County only covers rural counties and not metropolitan boroughs and other unitary authorities. Previously, there was a page full of local authorities (unitary authorities and districts), and each one of those would have a list of electoral wards. However, now there are counties that contain a list of districts - so this needs a new page - a checkbox for "select the county" and then a list of links to district pages. If you want to select multiple districts, you'll need to go into each one of those sub-sections in turn and click select all. Needed to tweak the query to retrieve the list of areas in a list for a library. Previously, it just returned anything at top level (ie: didn't have a parent). However, rural districts now have parents (the rural counties themselves). So the query now returns "everything that isn't a leaf node", or in more specific terms, everything that has at least other row referring to it as a parent. So no electoral wards, since they dont have any children, but yes to districts and counties.
2020-09-04 15:22:32 +01:00
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
add counties page What was previously ward -> local authority is now a ward -> local authority -> county. County only covers rural counties and not metropolitan boroughs and other unitary authorities. Previously, there was a page full of local authorities (unitary authorities and districts), and each one of those would have a list of electoral wards. However, now there are counties that contain a list of districts - so this needs a new page - a checkbox for "select the county" and then a list of links to district pages. If you want to select multiple districts, you'll need to go into each one of those sub-sections in turn and click select all. Needed to tweak the query to retrieve the list of areas in a list for a library. Previously, it just returned anything at top level (ie: didn't have a parent). However, rural districts now have parents (the rural counties themselves). So the query now returns "everything that isn't a leaf node", or in more specific terms, everything that has at least other row referring to it as a parent. So no electoral wards, since they dont have any children, but yes to districts and counties.
2020-09-04 15:22:32 +01:00
client_request.post(
'.choose_broadcast_sub_area',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
library_slug='wd20-lad20-ctyua19',
area_slug='ctyua19-E10000016', # Kent
_data={'select_all': 'y'},
)
Refactor `get_simple_polygons` method for reuse This means we: - don’t need to pass the areas around as an argument - keep all the complexity of combining polygons from different areas in one method
2021-09-01 20:14:14 +01:00
mock_get_polygons_from_areas.assert_called_once_with(area_attribute='simple_polygons')
add counties page What was previously ward -> local authority is now a ward -> local authority -> county. County only covers rural counties and not metropolitan boroughs and other unitary authorities. Previously, there was a page full of local authorities (unitary authorities and districts), and each one of those would have a list of electoral wards. However, now there are counties that contain a list of districts - so this needs a new page - a checkbox for "select the county" and then a list of links to district pages. If you want to select multiple districts, you'll need to go into each one of those sub-sections in turn and click select all. Needed to tweak the query to retrieve the list of areas in a list for a library. Previously, it just returned anything at top level (ie: didn't have a parent). However, rural districts now have parents (the rural counties themselves). So the query now returns "everything that isn't a leaf node", or in more specific terms, everything that has at least other row referring to it as a parent. So no electoral wards, since they dont have any children, but yes to districts and counties.
2020-09-04 15:22:32 +01:00
mock_update_broadcast_message.assert_called_once_with(
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
data={
Complete migration to new "areas" API format Depends on: https://github.com/alphagov/notifications-api/pull/3314 Previously: - We introduced a new "areas_2" API field that's can populate the "areas" column in the same way. - We updated the Admin app to use the new field, so that the old "areas" and "simple_polygons" API fields are unused. - We repurposed the unused "areas" API field to use the new "areas_2" format. This PR: - We can switch the Admin app back to the "areas" field, but in the new format. Future PRs: - Remove support for the unused "areas_2" field (migration complete)
2021-08-27 14:32:56 +01:00
'areas': {
Switch to using temporary "areas_2" API field Depends on: https://github.com/alphagov/notifications-api/pull/3312 This is part of a multi-stage migration where we want to repurpose the "areas" field in the existing API to something like "areas_2".
2021-08-25 17:17:05 +01:00
'simple_polygons': coordinates,
'ids': [
# These two areas are on the broadcast already
'ctry19-E92000001',
'ctry19-S92000003',
] + [
'ctyua19-E10000016'
Include area names in data we send to API These will be used as a fallback for display in gov.uk/alerts. It also helps to have them in the DB to aid in quickly identifying where an alert was sent, which is hard from the IDs. We will look at backfilling names for past alerts in future work.
2021-08-26 11:55:00 +01:00
],
Start sending aggregate area names to API The aggregate names don't need to be sorted, but it helps to do this for the tests, since the implementation of sets may not be stable between machines and lead to sporadic test failures. I did also toy with sorting granular area names so they have a similar ordering, but this would take them out-of-order with IDs and really the important thing is that the ordering is stable.
2021-08-27 14:58:45 +01:00
'names': ['England', 'Scotland', 'Kent'],
'aggregate_names': ['England', 'Kent', 'Scotland']
Switch to using temporary "areas_2" API field Depends on: https://github.com/alphagov/notifications-api/pull/3312 This is part of a multi-stage migration where we want to repurpose the "areas" field in the existing API to something like "areas_2".
2021-08-25 17:17:05 +01:00
}
add counties page What was previously ward -> local authority is now a ward -> local authority -> county. County only covers rural counties and not metropolitan boroughs and other unitary authorities. Previously, there was a page full of local authorities (unitary authorities and districts), and each one of those would have a list of electoral wards. However, now there are counties that contain a list of districts - so this needs a new page - a checkbox for "select the county" and then a list of links to district pages. If you want to select multiple districts, you'll need to go into each one of those sub-sections in turn and click select all. Needed to tweak the query to retrieve the list of areas in a list for a library. Previously, it just returned anything at top level (ie: didn't have a parent). However, rural districts now have parents (the rural counties themselves). So the query now returns "everything that isn't a leaf node", or in more specific terms, everything that has at least other row referring to it as a parent. So no electoral wards, since they dont have any children, but yes to districts and counties.
2020-09-04 15:22:32 +01:00
},
)
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
def test_remove_broadcast_area_page(
client_request,
service_one,
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
mock_get_draft_broadcast_message,
mock_update_broadcast_message,
fake_uuid,
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
mocker,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
):
service_one['permissions'] += ['broadcast']
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
polygon_class = namedtuple("polygon_class", ["as_coordinate_pairs_lat_long"])
coordinates = [[50.1, 0.1], [50.2, 0.2], [50.3, 0.2]]
polygons = polygon_class(as_coordinate_pairs_lat_long=coordinates)
Refactor `get_simple_polygons` method for reuse This means we: - don’t need to pass the areas around as an argument - keep all the complexity of combining polygons from different areas in one method
2021-09-01 20:14:14 +01:00
mock_get_polygons_from_areas = mocker.patch(
'app.models.broadcast_message.BroadcastMessage.get_polygons_from_areas',
return_value=polygons,
)
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
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
client_request.get(
'.remove_broadcast_area',
service_id=SERVICE_ONE_ID,
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=fake_uuid,
Rename electoral wards to local areas We’ve observed people using ‘national’ and ‘local’ during user research. It has less tongue-twisting ambiguity than county vs country. But we think that maybe just getting rid of ‘counties’ is enough to disambiguate them. So this commit just takes the ‘local’ concept. This commit also gives the libraries and areas new IDs, which means if we want to rename them in the future it won’t be a breaking change.
2020-08-13 12:25:22 +01:00
area_slug='ctry19-E92000001',
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
_expected_redirect=url_for(
'.preview_broadcast_areas',
service_id=SERVICE_ONE_ID,
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=fake_uuid,
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
_external=True,
),
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 `get_simple_polygons` method for reuse This means we: - don’t need to pass the areas around as an argument - keep all the complexity of combining polygons from different areas in one method
2021-09-01 20:14:14 +01:00
mock_get_polygons_from_areas.assert_called_once_with(area_attribute='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
mock_update_broadcast_message.assert_called_once_with(
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
data={
Complete migration to new "areas" API format Depends on: https://github.com/alphagov/notifications-api/pull/3314 Previously: - We introduced a new "areas_2" API field that's can populate the "areas" column in the same way. - We updated the Admin app to use the new field, so that the old "areas" and "simple_polygons" API fields are unused. - We repurposed the unused "areas" API field to use the new "areas_2" format. This PR: - We can switch the Admin app back to the "areas" field, but in the new format. Future PRs: - Remove support for the unused "areas_2" field (migration complete)
2021-08-27 14:32:56 +01:00
'areas': {
Switch to using temporary "areas_2" API field Depends on: https://github.com/alphagov/notifications-api/pull/3312 This is part of a multi-stage migration where we want to repurpose the "areas" field in the existing API to something like "areas_2".
2021-08-25 17:17:05 +01:00
'simple_polygons': coordinates,
Include area names in data we send to API These will be used as a fallback for display in gov.uk/alerts. It also helps to have them in the DB to aid in quickly identifying where an alert was sent, which is hard from the IDs. We will look at backfilling names for past alerts in future work.
2021-08-26 11:55:00 +01:00
'names': ['Scotland'],
Start sending aggregate area names to API The aggregate names don't need to be sorted, but it helps to do this for the tests, since the implementation of sets may not be stable between machines and lead to sporadic test failures. I did also toy with sorting granular area names so they have a similar ordering, but this would take them out-of-order with IDs and really the important thing is that the ordering is stable.
2021-08-27 14:58:45 +01:00
'aggregate_names': ['Scotland'],
Switch to using temporary "areas_2" API field Depends on: https://github.com/alphagov/notifications-api/pull/3312 This is part of a multi-stage migration where we want to repurpose the "areas" field in the existing API to something like "areas_2".
2021-08-25 17:17:05 +01:00
'ids': ['ctry19-S92000003']
},
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 some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
def test_preview_broadcast_message_page(
client_request,
service_one,
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
mock_get_draft_broadcast_message,
fake_uuid,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
):
service_one['permissions'] += ['broadcast']
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
Let users choose when to end a broadcast Different emergencies will need broadcasts to last for a variable amount of time. We give users some control over this by letting them stop a broadcast early. But we should also let them set a maximum broadcast time, for: - when the duration of the danger is known - when the broadcast has been live long enough to alert everyone who needs to know about it This code re-uses the pattern for scheduling jobs, which has some constraints that are probably OK for now: - end time is limited to an hour - longest duration is 3 whole days (eg if you start broadcasting Friday you have the choice of Saturday, Sunday and all of Monday, up to midnight)
2020-07-16 10:49:21 +01:00
page = client_request.get(
Add some views for selecting broadcast areas 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
2020-07-06 10:53:14 +01:00
'.preview_broadcast_message',
service_id=SERVICE_ONE_ID,
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=fake_uuid,
Let users choose when to end a broadcast Different emergencies will need broadcasts to last for a variable amount of time. We give users some control over this by letting them stop a broadcast early. But we should also let them set a maximum broadcast time, for: - when the duration of the danger is known - when the broadcast has been live long enough to alert everyone who needs to know about it This code re-uses the pattern for scheduling jobs, which has some constraints that are probably OK for now: - end time is limited to an hour - longest duration is 3 whole days (eg if you start broadcasting Friday you have the choice of Saturday, Sunday and all of Monday, up to midnight)
2020-07-16 10:49:21 +01:00
)
assert [
normalize_spaces(area.text)
for area in page.select('.area-list-item.area-list-item--unremoveable')
] == [
'England',
'Scotland',
]
Replace generated content with proper heading Brings in https://github.com/alphagov/notifications-utils/pull/797 but adapts the CSS so nothing changes visually
2020-10-06 10:09:25 +01:00
assert normalize_spaces(
page.select_one('h2.broadcast-message-heading').text
) == (
'Emergency alert'
)
Let users choose when to end a broadcast Different emergencies will need broadcasts to last for a variable amount of time. We give users some control over this by letting them stop a broadcast early. But we should also let them set a maximum broadcast time, for: - when the duration of the danger is known - when the broadcast has been live long enough to alert everyone who needs to know about it This code re-uses the pattern for scheduling jobs, which has some constraints that are probably OK for now: - end time is limited to an hour - longest duration is 3 whole days (eg if you start broadcasting Friday you have the choice of Saturday, Sunday and all of Monday, up to midnight)
2020-07-16 10:49:21 +01:00
assert normalize_spaces(
page.select_one('.broadcast-message-wrapper').text
) == (
Replace generated content with proper heading Brings in https://github.com/alphagov/notifications-utils/pull/797 but adapts the CSS so nothing changes visually
2020-10-06 10:09:25 +01:00
'Emergency alert '
Let users choose when to end a broadcast Different emergencies will need broadcasts to last for a variable amount of time. We give users some control over this by letting them stop a broadcast early. But we should also let them set a maximum broadcast time, for: - when the duration of the danger is known - when the broadcast has been live long enough to alert everyone who needs to know about it This code re-uses the pattern for scheduling jobs, which has some constraints that are probably OK for now: - end time is limited to an hour - longest duration is 3 whole days (eg if you start broadcasting Friday you have the choice of Saturday, Sunday and all of Monday, up to midnight)
2020-07-16 10:49:21 +01:00
'This is a test'
)
form = page.select_one('form')
assert form['method'] == 'post'
assert 'action' not in form
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 test_start_broadcasting(
client_request,
service_one,
mock_get_draft_broadcast_message,
mock_update_broadcast_message_status,
fake_uuid,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
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_one['permissions'] += ['broadcast']
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
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
client_request.post(
'.preview_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
Go to broadcast, not dashboard after submitting Once you’ve created a broadcast you’re taken back to the dashboard. This feels too passive, and you might miss that the broadcast still needs approval. We should be much more explicit that you now need to find someone to approve your broadcast. Taking someone directly to the page for a broadcast lets us give more information about the status of the broadcast and what the next steps should be.
2020-08-03 15:46:23 +01:00
_expected_redirect=url_for(
Ensure correct selected nav item on broadcast page Once a broadcast has been submitted for approval it either lives on the ‘Current alerts’ or ‘Previous alerts’ page, depending on where it is in its lifecycle. Therefore when clicking into a broadcast from one of those pages the same navigation item should remain selected. Because we select the navigation items based on the request endpoint, this means we need an endpoint for each navigation page, even if the content of the pages will be the same in both cases. This commit adds the two new end points, removes the old, single endpoint and updates links to point to the new endpoint.
2020-10-15 13:15:22 +01:00
'main.view_current_broadcast',
Go to broadcast, not dashboard after submitting Once you’ve created a broadcast you’re taken back to the dashboard. This feels too passive, and you might miss that the broadcast still needs approval. We should be much more explicit that you now need to find someone to approve your broadcast. Taking someone directly to the page for a broadcast lets us give more information about the status of the broadcast and what the next steps should be.
2020-08-03 15:46:23 +01:00
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
_external=True,
),
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
),
mock_update_broadcast_message_status.assert_called_once_with(
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
'pending-approval',
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=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
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
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
@pytest.mark.parametrize('endpoint, created_by_api, extra_fields, expected_paragraphs', (
('.view_current_broadcast', False, {
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
'status': 'broadcasting',
'finishes_at': '2020-02-23T23:23:23.000000',
}, [
Update tests for new content
2021-07-06 16:42:54 +01:00
'Live since 20 February at 8:20pm Stop sending',
Disambiguate sent and created At the moment we say that you either ‘add’ an alert or ‘send’ it. This is confusing because: - an alert isn’t received on people’s phones until it’s approved, so this is really when it is ‘sent’ conceptually - an alert can be rejected before anyone receives it, so the UI can say an alert that no-one ever received was sent This commit re-labels things so that the the first part of the process is ‘creating’ the alert. This makes all the permissions nice and distinct from each other. Adding templates and adding alerts feel conceptually quite different things (what are you adding the alert to?).
2021-07-22 14:27:22 +01:00
'Created by Alice and approved by Bob.',
Move end time to bottom of page End time is less important than the status of the broadcast, or when it was started (eg when it was received by most people in the area).
2020-10-14 14:05:14 +01:00
'Broadcasting stops tomorrow at 11:23pm.'
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
]),
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
('.view_current_broadcast', True, {
'status': 'broadcasting',
'finishes_at': '2020-02-23T23:23:23.000000',
}, [
Update tests for new content
2021-07-06 16:42:54 +01:00
'Live since 20 February at 8:20pm Stop sending',
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
'Created from an API call and approved by Alice.',
'Broadcasting stops tomorrow at 11:23pm.'
]),
('.view_previous_broadcast', False, {
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
'status': 'broadcasting',
'finishes_at': '2020-02-22T22:20:20.000000', # 2 mins before now()
}, [
Update tests for new content
2021-07-06 16:42:54 +01:00
'Sent on 20 February at 8:20pm.',
Disambiguate sent and created At the moment we say that you either ‘add’ an alert or ‘send’ it. This is confusing because: - an alert isn’t received on people’s phones until it’s approved, so this is really when it is ‘sent’ conceptually - an alert can be rejected before anyone receives it, so the UI can say an alert that no-one ever received was sent This commit re-labels things so that the the first part of the process is ‘creating’ the alert. This makes all the permissions nice and distinct from each other. Adding templates and adding alerts feel conceptually quite different things (what are you adding the alert to?).
2021-07-22 14:27:22 +01:00
'Created by Alice and approved by Bob.',
Move end time to bottom of page End time is less important than the status of the broadcast, or when it was started (eg when it was received by most people in the area).
2020-10-14 14:05:14 +01:00
'Finished broadcasting today at 10:20pm.'
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
]),
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
('.view_previous_broadcast', True, {
'status': 'broadcasting',
'finishes_at': '2020-02-22T22:20:20.000000', # 2 mins before now()
}, [
Update tests for new content
2021-07-06 16:42:54 +01:00
'Sent on 20 February at 8:20pm.',
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
'Created from an API call and approved by Alice.',
'Finished broadcasting today at 10:20pm.'
]),
('.view_previous_broadcast', False, {
Move end time to bottom of page End time is less important than the status of the broadcast, or when it was started (eg when it was received by most people in the area).
2020-10-14 14:05:14 +01:00
'status': 'completed',
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
'finishes_at': '2020-02-21T21:21:21.000000',
}, [
Update tests for new content
2021-07-06 16:42:54 +01:00
'Sent on 20 February at 8:20pm.',
Disambiguate sent and created At the moment we say that you either ‘add’ an alert or ‘send’ it. This is confusing because: - an alert isn’t received on people’s phones until it’s approved, so this is really when it is ‘sent’ conceptually - an alert can be rejected before anyone receives it, so the UI can say an alert that no-one ever received was sent This commit re-labels things so that the the first part of the process is ‘creating’ the alert. This makes all the permissions nice and distinct from each other. Adding templates and adding alerts feel conceptually quite different things (what are you adding the alert to?).
2021-07-22 14:27:22 +01:00
'Created by Alice and approved by Bob.',
Move end time to bottom of page End time is less important than the status of the broadcast, or when it was started (eg when it was received by most people in the area).
2020-10-14 14:05:14 +01:00
'Finished broadcasting yesterday at 9:21pm.',
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
]),
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
('.view_previous_broadcast', False, {
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
'status': 'cancelled',
'cancelled_by_id': sample_uuid,
'cancelled_at': '2020-02-21T21:21:21.000000',
}, [
Update tests for new content
2021-07-06 16:42:54 +01:00
'Sent on 20 February at 8:20pm.',
Disambiguate sent and created At the moment we say that you either ‘add’ an alert or ‘send’ it. This is confusing because: - an alert isn’t received on people’s phones until it’s approved, so this is really when it is ‘sent’ conceptually - an alert can be rejected before anyone receives it, so the UI can say an alert that no-one ever received was sent This commit re-labels things so that the the first part of the process is ‘creating’ the alert. This makes all the permissions nice and distinct from each other. Adding templates and adding alerts feel conceptually quite different things (what are you adding the alert to?).
2021-07-22 14:27:22 +01:00
'Created by Alice and approved by Bob.',
Move end time to bottom of page End time is less important than the status of the broadcast, or when it was started (eg when it was received by most people in the area).
2020-10-14 14:05:14 +01:00
'Stopped by Carol yesterday at 9:21pm.',
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
]),
Display if broadcast was cancelled via API If broadcast_message has no value under cancelled_by_id, display in the view that it was cancelled by an API call.
2022-01-18 12:23:20 +00:00
('.view_previous_broadcast', False, {
'status': 'cancelled',
'cancelled_by_id': None,
'cancelled_at': '2020-02-21T21:21:21.000000',
}, [
'Sent on 20 February at 8:20pm.',
'Created by Alice and approved by Bob.',
'Stopped by an API call yesterday at 9:21pm.',
]),
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
('.view_rejected_broadcast', False, {
'status': 'rejected',
'updated_at': '2020-02-21T21:21:21.000000',
}, [
'Rejected yesterday at 9:21pm.',
Disambiguate sent and created At the moment we say that you either ‘add’ an alert or ‘send’ it. This is confusing because: - an alert isn’t received on people’s phones until it’s approved, so this is really when it is ‘sent’ conceptually - an alert can be rejected before anyone receives it, so the UI can say an alert that no-one ever received was sent This commit re-labels things so that the the first part of the process is ‘creating’ the alert. This makes all the permissions nice and distinct from each other. Adding templates and adding alerts feel conceptually quite different things (what are you adding the alert to?).
2021-07-22 14:27:22 +01:00
'Created by Alice and approved by Bob.',
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
]),
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
))
@freeze_time('2020-02-22T22:22:22.000000')
def test_view_broadcast_message_page(
mocker,
client_request,
service_one,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_view_permissions,
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
fake_uuid,
Redirect to correct endpoint based on state If you refresh the page on a current broadcast while someone has cancelled it you’ll see the wrong navigation item selected. This commit adds redirects to take you to the correct endpoint in these edge cases.
2020-10-15 13:24:57 +01:00
endpoint,
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
created_by_api,
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
extra_fields,
expected_paragraphs,
):
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
service_id=SERVICE_ONE_ID,
template_id=fake_uuid,
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
created_by_id=None if created_by_api else fake_uuid,
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
approved_by_id=fake_uuid,
starts_at='2020-02-20T20:20:20.000000',
**extra_fields
),
)
mocker.patch('app.user_api_client.get_user', side_effect=[
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_view_permissions,
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
user_json(name='Alice'),
user_json(name='Bob'),
user_json(name='Carol'),
])
service_one['permissions'] += ['broadcast']
page = client_request.get(
Redirect to correct endpoint based on state If you refresh the page on a current broadcast while someone has cancelled it you’ll see the wrong navigation item selected. This commit adds redirects to take you to the correct endpoint in these edge cases.
2020-10-15 13:24:57 +01:00
endpoint,
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
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
assert [
normalize_spaces(p.text) for p in page.select('main p.govuk-body')
] == expected_paragraphs
Redirect to correct endpoint based on state If you refresh the page on a current broadcast while someone has cancelled it you’ll see the wrong navigation item selected. This commit adds redirects to take you to the correct endpoint in these edge cases.
2020-10-15 13:24:57 +01:00
@pytest.mark.parametrize('endpoint', (
'.view_current_broadcast',
'.view_previous_broadcast',
Add a separate page for rejected alerts We don’t want to mix these up with alerts that actually went out.
2021-04-08 13:09:29 +01:00
'.view_rejected_broadcast',
Redirect to correct endpoint based on state If you refresh the page on a current broadcast while someone has cancelled it you’ll see the wrong navigation item selected. This commit adds redirects to take you to the correct endpoint in these edge cases.
2020-10-15 13:24:57 +01:00
))
Add test for back link on view broadcast page
2020-10-26 11:06:27 +00:00
@pytest.mark.parametrize('status, expected_highlighted_navigation_item, expected_back_link_endpoint', (
Redirect to correct endpoint based on state If you refresh the page on a current broadcast while someone has cancelled it you’ll see the wrong navigation item selected. This commit adds redirects to take you to the correct endpoint in these edge cases.
2020-10-15 13:24:57 +01:00
(
'pending-approval',
'Current alerts',
Add test for back link on view broadcast page
2020-10-26 11:06:27 +00:00
'.broadcast_dashboard',
Redirect to correct endpoint based on state If you refresh the page on a current broadcast while someone has cancelled it you’ll see the wrong navigation item selected. This commit adds redirects to take you to the correct endpoint in these edge cases.
2020-10-15 13:24:57 +01:00
),
(
'broadcasting',
'Current alerts',
Add test for back link on view broadcast page
2020-10-26 11:06:27 +00:00
'.broadcast_dashboard',
Redirect to correct endpoint based on state If you refresh the page on a current broadcast while someone has cancelled it you’ll see the wrong navigation item selected. This commit adds redirects to take you to the correct endpoint in these edge cases.
2020-10-15 13:24:57 +01:00
),
(
'completed',
Change previous to past
2021-07-05 13:49:36 +01:00
'Past alerts',
Add test for back link on view broadcast page
2020-10-26 11:06:27 +00:00
'.broadcast_dashboard_previous',
Redirect to correct endpoint based on state If you refresh the page on a current broadcast while someone has cancelled it you’ll see the wrong navigation item selected. This commit adds redirects to take you to the correct endpoint in these edge cases.
2020-10-15 13:24:57 +01:00
),
(
'cancelled',
Update tests for new content
2021-07-06 16:42:54 +01:00
'Past alerts',
Add test for back link on view broadcast page
2020-10-26 11:06:27 +00:00
'.broadcast_dashboard_previous',
Redirect to correct endpoint based on state If you refresh the page on a current broadcast while someone has cancelled it you’ll see the wrong navigation item selected. This commit adds redirects to take you to the correct endpoint in these edge cases.
2020-10-15 13:24:57 +01:00
),
(
'rejected',
Add a separate page for rejected alerts We don’t want to mix these up with alerts that actually went out.
2021-04-08 13:09:29 +01:00
'Rejected alerts',
'.broadcast_dashboard_rejected',
Redirect to correct endpoint based on state If you refresh the page on a current broadcast while someone has cancelled it you’ll see the wrong navigation item selected. This commit adds redirects to take you to the correct endpoint in these edge cases.
2020-10-15 13:24:57 +01:00
),
))
@freeze_time('2020-02-22T22:22:22.000000')
def test_view_broadcast_message_shows_correct_highlighted_navigation(
mocker,
client_request,
service_one,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_approve_broadcasts_permission,
Redirect to correct endpoint based on state If you refresh the page on a current broadcast while someone has cancelled it you’ll see the wrong navigation item selected. This commit adds redirects to take you to the correct endpoint in these edge cases.
2020-10-15 13:24:57 +01:00
fake_uuid,
endpoint,
status,
expected_highlighted_navigation_item,
Add test for back link on view broadcast page
2020-10-26 11:06:27 +00:00
expected_back_link_endpoint,
Redirect to correct endpoint based on state If you refresh the page on a current broadcast while someone has cancelled it you’ll see the wrong navigation item selected. This commit adds redirects to take you to the correct endpoint in these edge cases.
2020-10-15 13:24:57 +01:00
):
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
service_id=SERVICE_ONE_ID,
template_id=fake_uuid,
created_by_id=fake_uuid,
approved_by_id=fake_uuid,
starts_at='2020-02-20T20:20:20.000000',
finishes_at='2021-12-21T21:21:21.000000',
cancelled_at='2021-01-01T01:01:01.000000',
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
updated_at='2021-01-01T01:01:01.000000',
Redirect to correct endpoint based on state If you refresh the page on a current broadcast while someone has cancelled it you’ll see the wrong navigation item selected. This commit adds redirects to take you to the correct endpoint in these edge cases.
2020-10-15 13:24:57 +01:00
status=status,
),
)
service_one['permissions'] += ['broadcast']
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_approve_broadcasts_permission)
Redirect to correct endpoint based on state If you refresh the page on a current broadcast while someone has cancelled it you’ll see the wrong navigation item selected. This commit adds redirects to take you to the correct endpoint in these edge cases.
2020-10-15 13:24:57 +01:00
page = client_request.get(
endpoint,
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
_follow_redirects=True
)
assert normalize_spaces(
page.select_one('.navigation .selected').text
) == (
expected_highlighted_navigation_item
)
Add test for back link on view broadcast page
2020-10-26 11:06:27 +00:00
assert page.select_one('.govuk-back-link')['href'] == url_for(
expected_back_link_endpoint,
service_id=SERVICE_ONE_ID,
)
Redirect to correct endpoint based on state If you refresh the page on a current broadcast while someone has cancelled it you’ll see the wrong navigation item selected. This commit adds redirects to take you to the correct endpoint in these edge cases.
2020-10-15 13:24:57 +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 test_view_pending_broadcast(
mocker,
client_request,
service_one,
fake_uuid,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_approve_broadcasts_permission,
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
):
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
broadcast_creator = create_active_user_create_broadcasts_permissions(with_unique_id=True)
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
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
service_id=SERVICE_ONE_ID,
template_id=fake_uuid,
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
created_by_id=broadcast_creator['id'],
Remove reference to end time for approver Messages awaiting approval don’t have an end time – it’s set automatically once the message is approved. We need to revisit the content on this page, but this is just a fix so that the page doesn’t `500`.
2020-08-20 10:08:33 +01:00
finishes_at=None,
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
status='pending-approval',
),
)
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_approve_broadcasts_permission)
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
mocker.patch('app.user_api_client.get_user', side_effect=[
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_approve_broadcasts_permission, # Current user
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
broadcast_creator, # User who created broadcast
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
])
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
service_one['permissions'] += ['broadcast']
page = client_request.get(
Ensure correct selected nav item on broadcast page Once a broadcast has been submitted for approval it either lives on the ‘Current alerts’ or ‘Previous alerts’ page, depending on where it is in its lifecycle. Therefore when clicking into a broadcast from one of those pages the same navigation item should remain selected. Because we select the navigation items based on the request endpoint, this means we need an endpoint for each navigation page, even if the content of the pages will be the same in both cases. This commit adds the two new end points, removes the old, single endpoint and updates links to point to the new endpoint.
2020-10-15 13:15:22 +01:00
'.view_current_broadcast',
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
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
assert (
normalize_spaces(page.select_one('.banner').text)
) == (
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
'Test User Create Broadcasts Permission wants to broadcast Example template '
Add a confirmation checkbox for live broadcasts We want people to be really sure before sending a live broadcast, not just clicking through the green buttons. This commit adds a checkbox which explains exactly the consequences of what they’re about to do, tailored to the channel they’re on, and the area chosen by the person creating the alert.
2021-05-12 13:26:13 +01:00
'No phones will get this alert. '
Let people approve own broadcasts in training mode We want to let users learn the system by trying it out. At the moment they can’t explore it fully by themselves because they’re blocked at the point of approving the broadcast, unless they involve in another member of their team. Having to involve another person is friction that will discourage people from exploring. So this adds a button that lets people approve their own broadcasts in trial mode, with some rough-and-ready content that explains training mode and how it would be different to trial mode.
2020-08-21 11:26:02 +01:00
'Start broadcasting now Reject this alert'
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
)
Add a confirmation checkbox for live broadcasts We want people to be really sure before sending a live broadcast, not just clicking through the green buttons. This commit adds a checkbox which explains exactly the consequences of what they’re about to do, tailored to the channel they’re on, and the area chosen by the person creating the alert.
2021-05-12 13:26:13 +01:00
assert not page.select('.banner input[type=checkbox]')
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
form = page.select_one('form.banner')
assert form['method'] == 'post'
assert 'action' not in form
assert form.select_one('button[type=submit]')
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
link = form.select_one('a.govuk-link.govuk-link--destructive')
Let people approve own broadcasts in training mode We want to let users learn the system by trying it out. At the moment they can’t explore it fully by themselves because they’re blocked at the point of approving the broadcast, unless they involve in another member of their team. Having to involve another person is friction that will discourage people from exploring. So this adds a button that lets people approve their own broadcasts in trial mode, with some rough-and-ready content that explains training mode and how it would be different to trial mode.
2020-08-21 11:26:02 +01:00
assert link.text == 'Reject this alert'
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
assert link['href'] == url_for(
'.reject_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
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
)
Prefer `cap_event` to `reference` when referring to an alert `reference` isn’t very human-friendly – the Environment Agency just supply a UUID in this field. The Environment Agency also populate the `<event>`` field with some human readable text, for example: > 013 Issue Severe Flood Warning EA (013 is an ‘area code’ which will be meaningful to the Flood Warning Service team) This commit changes the frontend to display the value of the `cap_event` field, if it’s present, which is where the API stores the value of the `<event>` field from the original CAP XML. *** Depends on: - [x] https://github.com/alphagov/notifications-api/pull/3344/files
2021-10-20 18:13:39 +01:00
@pytest.mark.parametrize('extra_broadcast_json_fields, expected_banner_text', (
:Use more realistic test data
2021-10-26 15:30:59 +01:00
({'reference': 'ABC123'}, (
'Test User Create Broadcasts Permission wants to broadcast ABC123 '
Prefer `cap_event` to `reference` when referring to an alert `reference` isn’t very human-friendly – the Environment Agency just supply a UUID in this field. The Environment Agency also populate the `<event>`` field with some human readable text, for example: > 013 Issue Severe Flood Warning EA (013 is an ‘area code’ which will be meaningful to the Flood Warning Service team) This commit changes the frontend to display the value of the `cap_event` field, if it’s present, which is where the API stores the value of the `<event>` field from the original CAP XML. *** Depends on: - [x] https://github.com/alphagov/notifications-api/pull/3344/files
2021-10-20 18:13:39 +01:00
'No phones will get this alert. '
'Start broadcasting now Reject this alert'
)),
:Use more realistic test data
2021-10-26 15:30:59 +01:00
({'cap_event': 'Severe flood warning', 'reference': 'ABC123'}, (
'Test User Create Broadcasts Permission wants to broadcast Severe flood warning '
Prefer `cap_event` to `reference` when referring to an alert `reference` isn’t very human-friendly – the Environment Agency just supply a UUID in this field. The Environment Agency also populate the `<event>`` field with some human readable text, for example: > 013 Issue Severe Flood Warning EA (013 is an ‘area code’ which will be meaningful to the Flood Warning Service team) This commit changes the frontend to display the value of the `cap_event` field, if it’s present, which is where the API stores the value of the `<event>` field from the original CAP XML. *** Depends on: - [x] https://github.com/alphagov/notifications-api/pull/3344/files
2021-10-20 18:13:39 +01:00
'No phones will get this alert. '
'Start broadcasting now Reject this alert'
)),
))
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
def test_view_pending_broadcast_without_template(
mocker,
client_request,
service_one,
fake_uuid,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_approve_broadcasts_permission,
Prefer `cap_event` to `reference` when referring to an alert `reference` isn’t very human-friendly – the Environment Agency just supply a UUID in this field. The Environment Agency also populate the `<event>`` field with some human readable text, for example: > 013 Issue Severe Flood Warning EA (013 is an ‘area code’ which will be meaningful to the Flood Warning Service team) This commit changes the frontend to display the value of the `cap_event` field, if it’s present, which is where the API stores the value of the `<event>` field from the original CAP XML. *** Depends on: - [x] https://github.com/alphagov/notifications-api/pull/3344/files
2021-10-20 18:13:39 +01:00
extra_broadcast_json_fields,
expected_banner_text,
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
):
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
broadcast_creator = create_active_user_create_broadcasts_permissions(with_unique_id=True)
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
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
service_id=SERVICE_ONE_ID,
template_id=None,
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
created_by_id=broadcast_creator['id'],
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
finishes_at=None,
status='pending-approval',
content='Uh-oh',
Prefer `cap_event` to `reference` when referring to an alert `reference` isn’t very human-friendly – the Environment Agency just supply a UUID in this field. The Environment Agency also populate the `<event>`` field with some human readable text, for example: > 013 Issue Severe Flood Warning EA (013 is an ‘area code’ which will be meaningful to the Flood Warning Service team) This commit changes the frontend to display the value of the `cap_event` field, if it’s present, which is where the API stores the value of the `<event>` field from the original CAP XML. *** Depends on: - [x] https://github.com/alphagov/notifications-api/pull/3344/files
2021-10-20 18:13:39 +01:00
**extra_broadcast_json_fields,
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
),
)
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_approve_broadcasts_permission)
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
mocker.patch('app.user_api_client.get_user', side_effect=[
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_approve_broadcasts_permission, # Current user
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
broadcast_creator, # User who created broadcast
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
])
service_one['permissions'] += ['broadcast']
page = client_request.get(
'.view_current_broadcast',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
assert (
normalize_spaces(page.select_one('.banner').text)
Prefer `cap_event` to `reference` when referring to an alert `reference` isn’t very human-friendly – the Environment Agency just supply a UUID in this field. The Environment Agency also populate the `<event>`` field with some human readable text, for example: > 013 Issue Severe Flood Warning EA (013 is an ‘area code’ which will be meaningful to the Flood Warning Service team) This commit changes the frontend to display the value of the `cap_event` field, if it’s present, which is where the API stores the value of the `<event>` field from the original CAP XML. *** Depends on: - [x] https://github.com/alphagov/notifications-api/pull/3344/files
2021-10-20 18:13:39 +01:00
) == expected_banner_text
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
assert (
normalize_spaces(page.select_one('.broadcast-message-wrapper').text)
) == (
'Emergency alert '
'Uh-oh'
)
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
def test_view_pending_broadcast_from_api_call(
mocker,
client_request,
service_one,
fake_uuid,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_approve_broadcasts_permission,
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
):
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
service_id=SERVICE_ONE_ID,
template_id=None,
created_by_id=None, # No user created this broadcast
finishes_at=None,
status='pending-approval',
reference='abc123',
content='Uh-oh',
),
)
service_one['permissions'] += ['broadcast']
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_approve_broadcasts_permission)
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
page = client_request.get(
'.view_current_broadcast',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
assert (
normalize_spaces(page.select_one('.banner').text)
) == (
'An API call wants to broadcast abc123 '
Add a confirmation checkbox for live broadcasts We want people to be really sure before sending a live broadcast, not just clicking through the green buttons. This commit adds a checkbox which explains exactly the consequences of what they’re about to do, tailored to the channel they’re on, and the area chosen by the person creating the alert.
2021-05-12 13:26:13 +01:00
'No phones will get this alert. '
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
'Start broadcasting now Reject this alert'
)
assert (
normalize_spaces(page.select_one('.broadcast-message-wrapper').text)
) == (
'Emergency alert '
'Uh-oh'
)
Add a confirmation checkbox for live broadcasts We want people to be really sure before sending a live broadcast, not just clicking through the green buttons. This commit adds a checkbox which explains exactly the consequences of what they’re about to do, tailored to the channel they’re on, and the area chosen by the person creating the alert.
2021-05-12 13:26:13 +01:00
@pytest.mark.parametrize('channel, expected_label_text', (
('test', (
'I understand this will alert anyone who has switched on the test channel'
)),
Add support for the operator channel Was just in one of those meetings where it felt like writing this would take less time than I’d already spent talking about its relative priority… --- In the admin app you can already set the broadcast channel as 'test', 'severe' or 'government'. Aim: - Add the 'operator' channel to the list of channels you can pick for the admin app broadcast services Note: - The API already supports this - https://github.com/alphagov/notifications-api/pull/3262 - The CBC proxy does not yet support the operator channel and this will need a separate card. That card has not yet been written because the interface has not been agreed between us and the MNOs yet. - Will need to have the ability to select the operator channel for just a single MNO like we do for the other channels - If we add this, we shouldn't actually start using it until the MNO in question gives us the go ahead. --- https://www.pivotaltracker.com/story/show/178485177
2021-06-11 12:03:38 +01:00
('operator', (
'I understand this will alert anyone who has switched on the operator channel'
)),
Add a confirmation checkbox for live broadcasts We want people to be really sure before sending a live broadcast, not just clicking through the green buttons. This commit adds a checkbox which explains exactly the consequences of what they’re about to do, tailored to the channel they’re on, and the area chosen by the person creating the alert.
2021-05-12 13:26:13 +01:00
('severe', (
'I understand this will alert millions of people'
)),
('government', (
'I understand this will alert millions of people, even if they’ve opted out'
)),
))
def test_checkbox_to_confirm_non_training_broadcasts(
mocker,
client_request,
service_one,
fake_uuid,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_approve_broadcasts_permission,
Add a confirmation checkbox for live broadcasts We want people to be really sure before sending a live broadcast, not just clicking through the green buttons. This commit adds a checkbox which explains exactly the consequences of what they’re about to do, tailored to the channel they’re on, and the area chosen by the person creating the alert.
2021-05-12 13:26:13 +01:00
channel,
expected_label_text,
):
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
service_id=SERVICE_ONE_ID,
template_id=None,
created_by_id=None,
status='pending-approval',
),
)
service_one['permissions'] += ['broadcast']
service_one['restricted'] = False
service_one['allowed_broadcast_provider'] = 'all'
service_one['broadcast_channel'] = channel
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_approve_broadcasts_permission)
Add a confirmation checkbox for live broadcasts We want people to be really sure before sending a live broadcast, not just clicking through the green buttons. This commit adds a checkbox which explains exactly the consequences of what they’re about to do, tailored to the channel they’re on, and the area chosen by the person creating the alert.
2021-05-12 13:26:13 +01:00
page = client_request.get(
'.view_current_broadcast',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
label = page.select_one('form.banner label')
assert label['for'] == 'confirm'
assert (
normalize_spaces(page.select_one('form.banner label').text)
) == expected_label_text
assert page.select_one('form.banner input[type=checkbox]')['name'] == 'confirm'
assert page.select_one('form.banner input[type=checkbox]')['value'] == 'y'
Show error message if checkbox wasn’t checked Because we were redirecting in all cases the error message wasn’t being shown. This commit changes the endpoint to respond with content (including an error message) if the `POST` is not successful.
2021-05-17 12:09:43 +01:00
def test_confirm_approve_non_training_broadcasts_errors_if_not_ticked(
mocker,
client_request,
service_one,
fake_uuid,
mock_update_broadcast_message,
mock_update_broadcast_message_status,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_approve_broadcasts_permission,
Show error message if checkbox wasn’t checked Because we were redirecting in all cases the error message wasn’t being shown. This commit changes the endpoint to respond with content (including an error message) if the `POST` is not successful.
2021-05-17 12:09:43 +01:00
):
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
service_id=SERVICE_ONE_ID,
template_id=None,
created_by_id=None,
status='pending-approval',
),
)
service_one['permissions'] += ['broadcast']
service_one['restricted'] = False
service_one['allowed_broadcast_provider'] = 'all'
Remove uneccessary parametrize It proves the behaviour isn't dependent on the channel, but there are other variables we could equally prove that for, which we're not testing here.
2021-05-18 15:16:15 +01:00
service_one['broadcast_channel'] = 'severe'
Show error message if checkbox wasn’t checked Because we were redirecting in all cases the error message wasn’t being shown. This commit changes the endpoint to respond with content (including an error message) if the `POST` is not successful.
2021-05-17 12:09:43 +01:00
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_approve_broadcasts_permission)
Show error message if checkbox wasn’t checked Because we were redirecting in all cases the error message wasn’t being shown. This commit changes the endpoint to respond with content (including an error message) if the `POST` is not successful.
2021-05-17 12:09:43 +01:00
page = client_request.post(
Test the POST `.approve_broadcast_message` explicitly in the code Previously, to get the the `.approve_broadcast_message` endpoint, we were issuing a POST request to `.view_current_broadcast`. The `.view_current_broadcast` only has a GET endpoint defined for the `/services/<uuid:service_id>/current-alerts/<uuid:broadcast_message_id>` route, so the request would end up at the `.approve_broadcast_message` which defines the POST endpoint for that path. This changes the tests to POST directly to `.approve_broadcast_message` to avoid confusion.
2021-07-23 16:56:37 +01:00
'.approve_broadcast_message',
Show error message if checkbox wasn’t checked Because we were redirecting in all cases the error message wasn’t being shown. This commit changes the endpoint to respond with content (including an error message) if the `POST` is not successful.
2021-05-17 12:09:43 +01:00
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
_data={},
_expected_status=200,
)
error_message = page.select_one('form.banner .govuk-error-message')
assert error_message['id'] == 'confirm-error'
assert normalize_spaces(error_message.text) == (
'Error: You need to confirm that you understand'
)
assert mock_update_broadcast_message.called is False
assert mock_update_broadcast_message_status.called is False
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
@freeze_time('2020-02-22T22:22:22.000000')
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
def test_can_approve_own_broadcast_in_training_mode(
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
mocker,
client_request,
service_one,
fake_uuid,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_approve_broadcasts_permission,
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
):
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
service_id=SERVICE_ONE_ID,
template_id=fake_uuid,
created_by_id=fake_uuid,
finishes_at='2020-02-23T23:23:23.000000',
status='pending-approval',
),
)
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_approve_broadcasts_permission)
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
mocker.patch('app.user_api_client.get_user', side_effect=[
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_approve_broadcasts_permission, # Current user
active_user_approve_broadcasts_permission, # User who created broadcast (the same)
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
])
service_one['permissions'] += ['broadcast']
page = client_request.get(
Ensure correct selected nav item on broadcast page Once a broadcast has been submitted for approval it either lives on the ‘Current alerts’ or ‘Previous alerts’ page, depending on where it is in its lifecycle. Therefore when clicking into a broadcast from one of those pages the same navigation item should remain selected. Because we select the navigation items based on the request endpoint, this means we need an endpoint for each navigation page, even if the content of the pages will be the same in both cases. This commit adds the two new end points, removes the old, single endpoint and updates links to point to the new endpoint.
2020-10-15 13:15:22 +01:00
'.view_current_broadcast',
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
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
assert (
Let people approve own broadcasts in training mode We want to let users learn the system by trying it out. At the moment they can’t explore it fully by themselves because they’re blocked at the point of approving the broadcast, unless they involve in another member of their team. Having to involve another person is friction that will discourage people from exploring. So this adds a button that lets people approve their own broadcasts in trial mode, with some rough-and-ready content that explains training mode and how it would be different to trial mode.
2020-08-21 11:26:02 +01:00
normalize_spaces(page.select_one('.banner h1').text)
) == (
'Example template is waiting for approval'
)
assert (
normalize_spaces(page.select_one('.banner p').text)
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
) == (
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
'When you use a live account you’ll need another member of '
'your team to approve your alert.'
)
assert (
normalize_spaces(page.select_one('.banner details summary').text)
) == (
'Approve your own alert'
)
assert (
normalize_spaces(page.select_one('.banner details ').text)
) == (
'Approve your own alert '
'Because you’re in training mode you can approve your own '
'alerts, to see how it works. '
'No real alerts will be broadcast to anyone’s phone. '
'Start broadcasting now '
'Reject this alert'
)
form = page.select_one('.banner details form')
assert form['method'] == 'post'
assert 'action' not in form
assert normalize_spaces(form.select_one('button[type=submit]').text) == (
'Start broadcasting now'
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
)
Let people approve own broadcasts in training mode We want to let users learn the system by trying it out. At the moment they can’t explore it fully by themselves because they’re blocked at the point of approving the broadcast, unless they involve in another member of their team. Having to involve another person is friction that will discourage people from exploring. So this adds a button that lets people approve their own broadcasts in trial mode, with some rough-and-ready content that explains training mode and how it would be different to trial mode.
2020-08-21 11:26:02 +01:00
link = page.select_one('.banner a.govuk-link.govuk-link--destructive')
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
assert link.text == 'Reject this alert'
Let people approve own broadcasts in training mode We want to let users learn the system by trying it out. At the moment they can’t explore it fully by themselves because they’re blocked at the point of approving the broadcast, unless they involve in another member of their team. Having to involve another person is friction that will discourage people from exploring. So this adds a button that lets people approve their own broadcasts in trial mode, with some rough-and-ready content that explains training mode and how it would be different to trial mode.
2020-08-21 11:26:02 +01:00
assert link['href'] == url_for(
'.reject_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
@freeze_time('2020-02-22T22:22:22.000000')
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
@pytest.mark.parametrize('user', [
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
create_active_user_approve_broadcasts_permissions(),
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
create_active_user_create_broadcasts_permissions(),
])
def test_cant_approve_own_broadcast_if_service_is_live(
Let people approve own broadcasts in training mode We want to let users learn the system by trying it out. At the moment they can’t explore it fully by themselves because they’re blocked at the point of approving the broadcast, unless they involve in another member of their team. Having to involve another person is friction that will discourage people from exploring. So this adds a button that lets people approve their own broadcasts in trial mode, with some rough-and-ready content that explains training mode and how it would be different to trial mode.
2020-08-21 11:26:02 +01:00
mocker,
client_request,
service_one,
fake_uuid,
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
user,
Let people approve own broadcasts in training mode We want to let users learn the system by trying it out. At the moment they can’t explore it fully by themselves because they’re blocked at the point of approving the broadcast, unless they involve in another member of their team. Having to involve another person is friction that will discourage people from exploring. So this adds a button that lets people approve their own broadcasts in trial mode, with some rough-and-ready content that explains training mode and how it would be different to trial mode.
2020-08-21 11:26:02 +01:00
):
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
service_one['restricted'] = False
Let people approve own broadcasts in training mode We want to let users learn the system by trying it out. At the moment they can’t explore it fully by themselves because they’re blocked at the point of approving the broadcast, unless they involve in another member of their team. Having to involve another person is friction that will discourage people from exploring. So this adds a button that lets people approve their own broadcasts in trial mode, with some rough-and-ready content that explains training mode and how it would be different to trial mode.
2020-08-21 11:26:02 +01:00
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
service_id=SERVICE_ONE_ID,
template_id=fake_uuid,
created_by_id=fake_uuid,
finishes_at='2020-02-23T23:23:23.000000',
status='pending-approval',
),
)
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
client_request.login(user)
Let people approve own broadcasts in training mode We want to let users learn the system by trying it out. At the moment they can’t explore it fully by themselves because they’re blocked at the point of approving the broadcast, unless they involve in another member of their team. Having to involve another person is friction that will discourage people from exploring. So this adds a button that lets people approve their own broadcasts in trial mode, with some rough-and-ready content that explains training mode and how it would be different to trial mode.
2020-08-21 11:26:02 +01:00
mocker.patch('app.user_api_client.get_user', side_effect=[
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
user, # Current user
user, # User who created broadcast (the same)
Let people approve own broadcasts in training mode We want to let users learn the system by trying it out. At the moment they can’t explore it fully by themselves because they’re blocked at the point of approving the broadcast, unless they involve in another member of their team. Having to involve another person is friction that will discourage people from exploring. So this adds a button that lets people approve their own broadcasts in trial mode, with some rough-and-ready content that explains training mode and how it would be different to trial mode.
2020-08-21 11:26:02 +01:00
])
service_one['permissions'] += ['broadcast']
page = client_request.get(
Ensure correct selected nav item on broadcast page Once a broadcast has been submitted for approval it either lives on the ‘Current alerts’ or ‘Previous alerts’ page, depending on where it is in its lifecycle. Therefore when clicking into a broadcast from one of those pages the same navigation item should remain selected. Because we select the navigation items based on the request endpoint, this means we need an endpoint for each navigation page, even if the content of the pages will be the same in both cases. This commit adds the two new end points, removes the old, single endpoint and updates links to point to the new endpoint.
2020-10-15 13:15:22 +01:00
'.view_current_broadcast',
Let people approve own broadcasts in training mode We want to let users learn the system by trying it out. At the moment they can’t explore it fully by themselves because they’re blocked at the point of approving the broadcast, unless they involve in another member of their team. Having to involve another person is friction that will discourage people from exploring. So this adds a button that lets people approve their own broadcasts in trial mode, with some rough-and-ready content that explains training mode and how it would be different to trial mode.
2020-08-21 11:26:02 +01:00
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
assert (
normalize_spaces(page.select_one('.banner h1').text)
) == (
'Example template is waiting for approval'
)
assert (
normalize_spaces(page.select_one('.banner p').text)
) == (
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
'You need another member of your team to approve your alert.'
Let people approve own broadcasts in training mode We want to let users learn the system by trying it out. At the moment they can’t explore it fully by themselves because they’re blocked at the point of approving the broadcast, unless they involve in another member of their team. Having to involve another person is friction that will discourage people from exploring. So this adds a button that lets people approve their own broadcasts in trial mode, with some rough-and-ready content that explains training mode and how it would be different to trial mode.
2020-08-21 11:26:02 +01:00
)
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
assert not page.select('form')
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
link = page.select_one('.banner a.govuk-link.govuk-link--destructive')
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
assert link.text == 'Discard this alert'
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
assert link['href'] == url_for(
'.reject_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
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
)
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
Let users without `send_messages` view broadcasts At the moment viewing a broadcast is limited to those users who have the `send_messages` permission. This doesn’t match how we describe the permissions on the team members page This commit makes it so that any team member can see a broadcast that’s in any state other than `draft`.
2020-08-10 12:13:11 +01:00
@freeze_time('2020-02-22T22:22:22.000000')
Admins won't see buttons for broadcast actions they can't do These actions are creating, accepting and rejecting broadcasts.
2021-04-14 18:13:18 +01:00
@pytest.mark.parametrize("user_is_platform_admin", [True, False])
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
def test_view_only_user_cant_approve_broadcast_created_by_someone_else(
Let users without `send_messages` view broadcasts At the moment viewing a broadcast is limited to those users who have the `send_messages` permission. This doesn’t match how we describe the permissions on the team members page This commit makes it so that any team member can see a broadcast that’s in any state other than `draft`.
2020-08-10 12:13:11 +01:00
mocker,
client_request,
service_one,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
Let users without `send_messages` view broadcasts At the moment viewing a broadcast is limited to those users who have the `send_messages` permission. This doesn’t match how we describe the permissions on the team members page This commit makes it so that any team member can see a broadcast that’s in any state other than `draft`.
2020-08-10 12:13:11 +01:00
active_user_view_permissions,
Admins won't see buttons for broadcast actions they can't do These actions are creating, accepting and rejecting broadcasts.
2021-04-14 18:13:18 +01:00
platform_admin_user_no_service_permissions,
Let users without `send_messages` view broadcasts At the moment viewing a broadcast is limited to those users who have the `send_messages` permission. This doesn’t match how we describe the permissions on the team members page This commit makes it so that any team member can see a broadcast that’s in any state other than `draft`.
2020-08-10 12:13:11 +01:00
fake_uuid,
Admins won't see buttons for broadcast actions they can't do These actions are creating, accepting and rejecting broadcasts.
2021-04-14 18:13:18 +01:00
user_is_platform_admin
Let users without `send_messages` view broadcasts At the moment viewing a broadcast is limited to those users who have the `send_messages` permission. This doesn’t match how we describe the permissions on the team members page This commit makes it so that any team member can see a broadcast that’s in any state other than `draft`.
2020-08-10 12:13:11 +01:00
):
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
service_id=SERVICE_ONE_ID,
template_id=fake_uuid,
created_by_id=fake_uuid,
finishes_at='2020-02-23T23:23:23.000000',
status='pending-approval',
),
)
Admins won't see buttons for broadcast actions they can't do These actions are creating, accepting and rejecting broadcasts.
2021-04-14 18:13:18 +01:00
if user_is_platform_admin:
current_user = platform_admin_user_no_service_permissions
else:
current_user = active_user_view_permissions
Let users without `send_messages` view broadcasts At the moment viewing a broadcast is limited to those users who have the `send_messages` permission. This doesn’t match how we describe the permissions on the team members page This commit makes it so that any team member can see a broadcast that’s in any state other than `draft`.
2020-08-10 12:13:11 +01:00
mocker.patch('app.user_api_client.get_user', side_effect=[
Admins won't see buttons for broadcast actions they can't do These actions are creating, accepting and rejecting broadcasts.
2021-04-14 18:13:18 +01:00
current_user, # Current user
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission, # User who created broadcast
Let users without `send_messages` view broadcasts At the moment viewing a broadcast is limited to those users who have the `send_messages` permission. This doesn’t match how we describe the permissions on the team members page This commit makes it so that any team member can see a broadcast that’s in any state other than `draft`.
2020-08-10 12:13:11 +01:00
])
service_one['permissions'] += ['broadcast']
page = client_request.get(
Ensure correct selected nav item on broadcast page Once a broadcast has been submitted for approval it either lives on the ‘Current alerts’ or ‘Previous alerts’ page, depending on where it is in its lifecycle. Therefore when clicking into a broadcast from one of those pages the same navigation item should remain selected. Because we select the navigation items based on the request endpoint, this means we need an endpoint for each navigation page, even if the content of the pages will be the same in both cases. This commit adds the two new end points, removes the old, single endpoint and updates links to point to the new endpoint.
2020-10-15 13:15:22 +01:00
'.view_current_broadcast',
Let users without `send_messages` view broadcasts At the moment viewing a broadcast is limited to those users who have the `send_messages` permission. This doesn’t match how we describe the permissions on the team members page This commit makes it so that any team member can see a broadcast that’s in any state other than `draft`.
2020-08-10 12:13:11 +01:00
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
assert (
normalize_spaces(page.select_one('.banner').text)
) == (
Let people approve own broadcasts in training mode We want to let users learn the system by trying it out. At the moment they can’t explore it fully by themselves because they’re blocked at the point of approving the broadcast, unless they involve in another member of their team. Having to involve another person is friction that will discourage people from exploring. So this adds a button that lets people approve their own broadcasts in trial mode, with some rough-and-ready content that explains training mode and how it would be different to trial mode.
2020-08-21 11:26:02 +01:00
'This alert is waiting for approval '
'You don’t have permission to approve alerts.'
Let users without `send_messages` view broadcasts At the moment viewing a broadcast is limited to those users who have the `send_messages` permission. This doesn’t match how we describe the permissions on the team members page This commit makes it so that any team member can see a broadcast that’s in any state other than `draft`.
2020-08-10 12:13:11 +01:00
)
assert not page.select_one('form')
assert not page.select_one('.banner a')
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
def test_view_only_user_cant_approve_broadcasts_they_created(
mocker,
client_request,
service_one,
fake_uuid,
Remove `active_user_broadcast_permissions` fixture This wasn't adding anything now that we have two new and more specific fixtures, `active_user_create_broadcasts_permission` and `active_user_approve_broadcasts_permission`, that can be used instead. `manage_templates` has now been removed from the `create_broadcasts` permission, so this also adjusts the fixture for a user who can create broadcasts.
2021-07-22 17:35:30 +01:00
active_user_create_broadcasts_permission,
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
active_user_view_permissions,
):
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
service_id=SERVICE_ONE_ID,
template_id=fake_uuid,
created_by_id=fake_uuid,
finishes_at='2020-02-23T23:23:23.000000',
status='pending-approval',
),
)
client_request.login(active_user_view_permissions)
Remove `active_user_broadcast_permissions` fixture This wasn't adding anything now that we have two new and more specific fixtures, `active_user_create_broadcasts_permission` and `active_user_approve_broadcasts_permission`, that can be used instead. `manage_templates` has now been removed from the `create_broadcasts` permission, so this also adjusts the fixture for a user who can create broadcasts.
2021-07-22 17:35:30 +01:00
# active_user_view_permissions and active_user_create_broadcasts_permission have the same
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
# id. This mocks the same user being returned, but with different permissions each time.
mocker.patch('app.user_api_client.get_user', side_effect=[
active_user_view_permissions, # Current user
Remove `active_user_broadcast_permissions` fixture This wasn't adding anything now that we have two new and more specific fixtures, `active_user_create_broadcasts_permission` and `active_user_approve_broadcasts_permission`, that can be used instead. `manage_templates` has now been removed from the `create_broadcasts` permission, so this also adjusts the fixture for a user who can create broadcasts.
2021-07-22 17:35:30 +01:00
active_user_create_broadcasts_permission, # User who created broadcast
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
])
service_one['permissions'] += ['broadcast']
service_one['restriced'] = False
page = client_request.get(
'.view_current_broadcast',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
assert (
normalize_spaces(page.select_one('.banner').text)
) == (
'This alert is waiting for approval '
'You don’t have permission to approve alerts.'
)
assert not page.select_one('form')
assert not page.select_one('.banner a')
@pytest.mark.parametrize('is_service_training_mode,banner_text', [
(
True,
('This alert is waiting for approval '
'Another member of your team needs to approve this alert. '
'This service is in training mode. No real alerts will be sent. '
'Reject this alert')
),
(
False,
('This alert is waiting for approval '
'Another member of your team needs to approve this alert. '
'Reject this alert')
)
])
def test_user_without_approve_permission_cant_approve_broadcast_created_by_someone_else(
mocker,
client_request,
service_one,
Remove `active_user_broadcast_permissions` fixture This wasn't adding anything now that we have two new and more specific fixtures, `active_user_create_broadcasts_permission` and `active_user_approve_broadcasts_permission`, that can be used instead. `manage_templates` has now been removed from the `create_broadcasts` permission, so this also adjusts the fixture for a user who can create broadcasts.
2021-07-22 17:35:30 +01:00
active_user_create_broadcasts_permission,
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
fake_uuid,
is_service_training_mode,
banner_text,
):
current_user = create_active_user_create_broadcasts_permissions(with_unique_id=True)
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
service_id=SERVICE_ONE_ID,
template_id=fake_uuid,
created_by_id=fake_uuid,
finishes_at='2020-02-23T23:23:23.000000',
status='pending-approval',
),
)
client_request.login(current_user)
mocker.patch('app.user_api_client.get_user', side_effect=[
current_user, # Current user
Remove `active_user_broadcast_permissions` fixture This wasn't adding anything now that we have two new and more specific fixtures, `active_user_create_broadcasts_permission` and `active_user_approve_broadcasts_permission`, that can be used instead. `manage_templates` has now been removed from the `create_broadcasts` permission, so this also adjusts the fixture for a user who can create broadcasts.
2021-07-22 17:35:30 +01:00
active_user_create_broadcasts_permission, # User who created broadcast
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
])
service_one['permissions'] += ['broadcast']
service_one['restricted'] = is_service_training_mode
page = client_request.get(
'.view_current_broadcast',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
assert (
normalize_spaces(page.select_one('.banner').text)
) == banner_text
assert not page.select_one('form')
link = page.select_one('.banner a')
assert link['href'] == url_for('.reject_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid)
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
def test_user_without_approve_permission_cant_approve_broadcast_they_created(
mocker,
client_request,
service_one,
fake_uuid,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
):
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
service_id=SERVICE_ONE_ID,
template_id=fake_uuid,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
created_by_id=active_user_create_broadcasts_permission['id'],
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
finishes_at=None,
status='pending-approval',
),
)
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
mocker.patch('app.user_api_client.get_user', side_effect=[
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission, # Current user
active_user_create_broadcasts_permission, # Same created the broadcast
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
])
service_one['permissions'] += ['broadcast']
page = client_request.get(
'.view_current_broadcast',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
assert (
normalize_spaces(page.select_one('.banner').text)
) == (
'Example template is waiting for approval '
'You need another member of your team to approve this alert. '
'This service is in training mode. No real alerts will be sent. '
'Discard this alert'
)
assert not page.select('.banner input[type=checkbox]')
link = page.select_one('a.govuk-link.govuk-link--destructive')
assert link.text == 'Discard this alert'
assert link['href'] == url_for(
'.reject_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
Expire test and operator alerts after 4 hours While testing alerts on these channels the MNOs sometimes need to restart their CBCs to make sure everything is failing over properly. If the CBC does not come back up, for whatever reason, then we are left in a state where the alert can’t be cancelled. To minimise the impact to the public in this scenario we should keep the expiry time at 4 hours for alerts sent on test channels. We recently increased it back up to 24 hours for all channels, so this in effect is reverting that change for channels that won’t be used in a real emergency.
2021-08-09 15:01:06 +01:00
@pytest.mark.parametrize('channel, expected_finishes_at', (
# 4 hours later
('operator', '2020-02-23T02:22:22'),
('test', '2020-02-23T02:22:22'),
Reduce expiry time to 22 hours 30 minutes Theoretically the maximum expiry time of a broadcast should be 24 hours. If it goes over 24 hours there can be problems. However we want to make it more conservative to mitigate two potential issues: 1. The CBC has a repetition period (eg 60 seconds) and a count (eg 1,440). If these were slightly innaccurate or generous it could take us over 24 hours. For this reason we should give ourselves half an hour of buffer. 2. It’s possibly that the CBC could interpret a UTC time as BST or vice versa. Until we’re sure that it’s using UTC everywhere, we need to remove another whole hour as buffer. In total this means we remove 1 hour 30 minutes from 24 hours, giving an expiry time of 22 hours 30 minutes.
2021-08-10 13:41:03 +01:00
# 22 hours 30 minutes later
('severe', '2020-02-23T20:52:22'),
('government', '2020-02-23T20:52:22'),
(None, '2020-02-23T20:52:22'), # Training mode
Expire test and operator alerts after 4 hours While testing alerts on these channels the MNOs sometimes need to restart their CBCs to make sure everything is failing over properly. If the CBC does not come back up, for whatever reason, then we are left in a state where the alert can’t be cancelled. To minimise the impact to the public in this scenario we should keep the expiry time at 4 hours for alerts sent on test channels. We recently increased it back up to 24 hours for all channels, so this in effect is reverting that change for channels that won’t be used in a real emergency.
2021-08-09 15:01:06 +01:00
))
Show error message if checkbox wasn’t checked Because we were redirecting in all cases the error message wasn’t being shown. This commit changes the endpoint to respond with content (including an error message) if the `POST` is not successful.
2021-05-17 12:09:43 +01:00
@pytest.mark.parametrize(
Remove duplicative test This case was already covered by `test_confirm_approve_non_training_broadcasts_errors_if_not_ticked`
2021-05-18 15:11:42 +01:00
'trial_mode, initial_status, post_data, expected_approval, expected_redirect',
Show error message if checkbox wasn’t checked Because we were redirecting in all cases the error message wasn’t being shown. This commit changes the endpoint to respond with content (including an error message) if the `POST` is not successful.
2021-05-17 12:09:43 +01:00
(
(True, 'draft', {}, False, partial(
url_for,
'.view_current_broadcast',
broadcast_message_id=sample_uuid,
Remove duplicative test This case was already covered by `test_confirm_approve_non_training_broadcasts_errors_if_not_ticked`
2021-05-18 15:11:42 +01:00
)),
Show error message if checkbox wasn’t checked Because we were redirecting in all cases the error message wasn’t being shown. This commit changes the endpoint to respond with content (including an error message) if the `POST` is not successful.
2021-05-17 12:09:43 +01:00
(True, 'pending-approval', {}, True, partial(
url_for,
'.broadcast_tour',
step_index=6,
Remove duplicative test This case was already covered by `test_confirm_approve_non_training_broadcasts_errors_if_not_ticked`
2021-05-18 15:11:42 +01:00
)),
Show error message if checkbox wasn’t checked Because we were redirecting in all cases the error message wasn’t being shown. This commit changes the endpoint to respond with content (including an error message) if the `POST` is not successful.
2021-05-17 12:09:43 +01:00
(False, 'pending-approval', {'confirm': 'y'}, True, partial(
url_for,
'.view_current_broadcast',
broadcast_message_id=sample_uuid,
Remove duplicative test This case was already covered by `test_confirm_approve_non_training_broadcasts_errors_if_not_ticked`
2021-05-18 15:11:42 +01:00
)),
Show error message if checkbox wasn’t checked Because we were redirecting in all cases the error message wasn’t being shown. This commit changes the endpoint to respond with content (including an error message) if the `POST` is not successful.
2021-05-17 12:09:43 +01:00
(True, 'rejected', {}, False, partial(
url_for,
'.view_current_broadcast',
broadcast_message_id=sample_uuid,
Remove duplicative test This case was already covered by `test_confirm_approve_non_training_broadcasts_errors_if_not_ticked`
2021-05-18 15:11:42 +01:00
)),
Show error message if checkbox wasn’t checked Because we were redirecting in all cases the error message wasn’t being shown. This commit changes the endpoint to respond with content (including an error message) if the `POST` is not successful.
2021-05-17 12:09:43 +01:00
(True, 'broadcasting', {}, False, partial(
url_for,
'.view_current_broadcast',
broadcast_message_id=sample_uuid,
Remove duplicative test This case was already covered by `test_confirm_approve_non_training_broadcasts_errors_if_not_ticked`
2021-05-18 15:11:42 +01:00
)),
Show error message if checkbox wasn’t checked Because we were redirecting in all cases the error message wasn’t being shown. This commit changes the endpoint to respond with content (including an error message) if the `POST` is not successful.
2021-05-17 12:09:43 +01:00
(True, 'cancelled', {}, False, partial(
url_for,
'.view_current_broadcast',
broadcast_message_id=sample_uuid,
Remove duplicative test This case was already covered by `test_confirm_approve_non_training_broadcasts_errors_if_not_ticked`
2021-05-18 15:11:42 +01:00
)),
Show error message if checkbox wasn’t checked Because we were redirecting in all cases the error message wasn’t being shown. This commit changes the endpoint to respond with content (including an error message) if the `POST` is not successful.
2021-05-17 12:09:43 +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
@freeze_time('2020-02-22T22:22:22.000000')
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
def test_confirm_approve_broadcast(
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
mocker,
client_request,
service_one,
fake_uuid,
mock_update_broadcast_message,
mock_update_broadcast_message_status,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_approve_broadcasts_permission,
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
initial_status,
Add a confirmation checkbox for live broadcasts We want people to be really sure before sending a live broadcast, not just clicking through the green buttons. This commit adds a checkbox which explains exactly the consequences of what they’re about to do, tailored to the channel they’re on, and the area chosen by the person creating the alert.
2021-05-12 13:26:13 +01:00
post_data,
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
expected_approval,
Add a tour screen once a broadcast is approved For a training broadcast the user doesn’t get that immediate feedback that something has happened, like they would with a real alert, or even sending themselves a text message. This commit adds another tour-style page which will interrupt their journey and hopefully reinforce the message we’ve given them earlier in the tour. We’re adding this because we’ve found in research that users don’t have a good grasp of the consequences and severity of emergency alerts, versus regular text messages.
2020-09-21 09:41:19 +01:00
trial_mode,
expected_redirect,
Expire test and operator alerts after 4 hours While testing alerts on these channels the MNOs sometimes need to restart their CBCs to make sure everything is failing over properly. If the CBC does not come back up, for whatever reason, then we are left in a state where the alert can’t be cancelled. To minimise the impact to the public in this scenario we should keep the expiry time at 4 hours for alerts sent on test channels. We recently increased it back up to 24 hours for all channels, so this in effect is reverting that change for channels that won’t be used in a real emergency.
2021-08-09 15:01:06 +01:00
channel,
expected_finishes_at,
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
):
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
service_id=SERVICE_ONE_ID,
template_id=fake_uuid,
created_by_id=fake_uuid,
finishes_at='2020-02-23T23:23:23.000000',
status=initial_status,
),
)
Add a tour screen once a broadcast is approved For a training broadcast the user doesn’t get that immediate feedback that something has happened, like they would with a real alert, or even sending themselves a text message. This commit adds another tour-style page which will interrupt their journey and hopefully reinforce the message we’ve given them earlier in the tour. We’re adding this because we’ve found in research that users don’t have a good grasp of the consequences and severity of emergency alerts, versus regular text messages.
2020-09-21 09:41:19 +01:00
service_one['restricted'] = trial_mode
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
service_one['permissions'] += ['broadcast']
Expire test and operator alerts after 4 hours While testing alerts on these channels the MNOs sometimes need to restart their CBCs to make sure everything is failing over properly. If the CBC does not come back up, for whatever reason, then we are left in a state where the alert can’t be cancelled. To minimise the impact to the public in this scenario we should keep the expiry time at 4 hours for alerts sent on test channels. We recently increased it back up to 24 hours for all channels, so this in effect is reverting that change for channels that won’t be used in a real emergency.
2021-08-09 15:01:06 +01:00
service_one['broadcast_channel'] = channel
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
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_approve_broadcasts_permission)
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
client_request.post(
Test the POST `.approve_broadcast_message` explicitly in the code Previously, to get the the `.approve_broadcast_message` endpoint, we were issuing a POST request to `.view_current_broadcast`. The `.view_current_broadcast` only has a GET endpoint defined for the `/services/<uuid:service_id>/current-alerts/<uuid:broadcast_message_id>` route, so the request would end up at the `.approve_broadcast_message` which defines the POST endpoint for that path. This changes the tests to POST directly to `.approve_broadcast_message` to avoid confusion.
2021-07-23 16:56:37 +01:00
'.approve_broadcast_message',
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
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
Add a tour screen once a broadcast is approved For a training broadcast the user doesn’t get that immediate feedback that something has happened, like they would with a real alert, or even sending themselves a text message. This commit adds another tour-style page which will interrupt their journey and hopefully reinforce the message we’ve given them earlier in the tour. We’re adding this because we’ve found in research that users don’t have a good grasp of the consequences and severity of emergency alerts, versus regular text messages.
2020-09-21 09:41:19 +01:00
_expected_redirect=expected_redirect(
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
service_id=SERVICE_ONE_ID,
_external=True,
Add a confirmation checkbox for live broadcasts We want people to be really sure before sending a live broadcast, not just clicking through the green buttons. This commit adds a checkbox which explains exactly the consequences of what they’re about to do, tailored to the channel they’re on, and the area chosen by the person creating the alert.
2021-05-12 13:26:13 +01:00
),
_data=post_data,
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
)
if expected_approval:
mock_update_broadcast_message.assert_called_once_with(
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
data={
'starts_at': '2020-02-22T22:22:22',
Expire test and operator alerts after 4 hours While testing alerts on these channels the MNOs sometimes need to restart their CBCs to make sure everything is failing over properly. If the CBC does not come back up, for whatever reason, then we are left in a state where the alert can’t be cancelled. To minimise the impact to the public in this scenario we should keep the expiry time at 4 hours for alerts sent on test channels. We recently increased it back up to 24 hours for all channels, so this in effect is reverting that change for channels that won’t be used in a real emergency.
2021-08-09 15:01:06 +01:00
'finishes_at': expected_finishes_at,
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
},
)
mock_update_broadcast_message_status.assert_called_once_with(
'broadcasting',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
else:
assert mock_update_broadcast_message.called is False
assert mock_update_broadcast_message_status.called is False
Allow users with new broadcast permissions access to routes Added two new permissions - `create_broadcasts` and `approve_broadcasts`. These new permissions get added to the `has_permissions` decorator of the broadcast routes to allow the routes to be accessed with either the old permissions on the new ones while we switch over. We were using the `send_messages` permission for the broadcast routes. By having two new permissions we can allow a more granular control of these routes.
2021-06-17 18:03:58 +01:00
@pytest.mark.parametrize('user', (
create_active_user_create_broadcasts_permissions(),
create_active_user_approve_broadcasts_permissions(),
))
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
@freeze_time('2020-02-22T22:22:22.000000')
def test_reject_broadcast(
mocker,
client_request,
service_one,
fake_uuid,
mock_update_broadcast_message,
mock_update_broadcast_message_status,
Allow users with new broadcast permissions access to routes Added two new permissions - `create_broadcasts` and `approve_broadcasts`. These new permissions get added to the `has_permissions` decorator of the broadcast routes to allow the routes to be accessed with either the old permissions on the new ones while we switch over. We were using the `send_messages` permission for the broadcast routes. By having two new permissions we can allow a more granular control of these routes.
2021-06-17 18:03:58 +01:00
user,
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
):
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
service_id=SERVICE_ONE_ID,
template_id=fake_uuid,
created_by_id=fake_uuid,
finishes_at='2020-02-23T23:23:23.000000',
status='pending-approval',
),
)
service_one['permissions'] += ['broadcast']
Allow users with new broadcast permissions access to routes Added two new permissions - `create_broadcasts` and `approve_broadcasts`. These new permissions get added to the `has_permissions` decorator of the broadcast routes to allow the routes to be accessed with either the old permissions on the new ones while we switch over. We were using the `send_messages` permission for the broadcast routes. By having two new permissions we can allow a more granular control of these routes.
2021-06-17 18:03:58 +01:00
client_request.login(user)
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
client_request.get(
'.reject_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
_expected_redirect=url_for(
'.broadcast_dashboard',
service_id=SERVICE_ONE_ID,
_external=True,
)
)
assert mock_update_broadcast_message.called is False
mock_update_broadcast_message_status.assert_called_once_with(
'rejected',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
@pytest.mark.parametrize('user', [
create_active_user_create_broadcasts_permissions(),
create_active_user_approve_broadcasts_permissions(),
])
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
@pytest.mark.parametrize('initial_status', (
'draft',
'rejected',
'broadcasting',
'cancelled',
))
@freeze_time('2020-02-22T22:22:22.000000')
def test_cant_reject_broadcast_in_wrong_state(
mocker,
client_request,
service_one,
mock_get_broadcast_template,
fake_uuid,
mock_update_broadcast_message,
mock_update_broadcast_message_status,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
user,
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
initial_status,
):
mocker.patch(
'app.broadcast_message_api_client.get_broadcast_message',
return_value=broadcast_message_json(
id_=fake_uuid,
service_id=SERVICE_ONE_ID,
template_id=fake_uuid,
created_by_id=fake_uuid,
finishes_at='2020-02-23T23:23:23.000000',
status=initial_status,
),
)
service_one['permissions'] += ['broadcast']
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(user)
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
client_request.get(
'.reject_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
_expected_redirect=url_for(
Ensure correct selected nav item on broadcast page Once a broadcast has been submitted for approval it either lives on the ‘Current alerts’ or ‘Previous alerts’ page, depending on where it is in its lifecycle. Therefore when clicking into a broadcast from one of those pages the same navigation item should remain selected. Because we select the navigation items based on the request endpoint, this means we need an endpoint for each navigation page, even if the content of the pages will be the same in both cases. This commit adds the two new end points, removes the old, single endpoint and updates links to point to the new endpoint.
2020-10-15 13:15:22 +01:00
'.view_current_broadcast',
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
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
_external=True,
)
)
assert mock_update_broadcast_message.called is False
assert mock_update_broadcast_message_status.called is False
Ensure correct selected nav item on broadcast page Once a broadcast has been submitted for approval it either lives on the ‘Current alerts’ or ‘Previous alerts’ page, depending on where it is in its lifecycle. Therefore when clicking into a broadcast from one of those pages the same navigation item should remain selected. Because we select the navigation items based on the request endpoint, this means we need an endpoint for each navigation page, even if the content of the pages will be the same in both cases. This commit adds the two new end points, removes the old, single endpoint and updates links to point to the new endpoint.
2020-10-15 13:15:22 +01:00
@pytest.mark.parametrize('endpoint', (
'.view_current_broadcast',
'.view_previous_broadcast',
))
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 test_no_view_page_for_draft(
client_request,
service_one,
mock_get_draft_broadcast_message,
fake_uuid,
Ensure correct selected nav item on broadcast page Once a broadcast has been submitted for approval it either lives on the ‘Current alerts’ or ‘Previous alerts’ page, depending on where it is in its lifecycle. Therefore when clicking into a broadcast from one of those pages the same navigation item should remain selected. Because we select the navigation items based on the request endpoint, this means we need an endpoint for each navigation page, even if the content of the pages will be the same in both cases. This commit adds the two new end points, removes the old, single endpoint and updates links to point to the new endpoint.
2020-10-15 13:15:22 +01:00
endpoint,
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
):
service_one['permissions'] += ['broadcast']
client_request.get(
Ensure correct selected nav item on broadcast page Once a broadcast has been submitted for approval it either lives on the ‘Current alerts’ or ‘Previous alerts’ page, depending on where it is in its lifecycle. Therefore when clicking into a broadcast from one of those pages the same navigation item should remain selected. Because we select the navigation items based on the request endpoint, this means we need an endpoint for each navigation page, even if the content of the pages will be the same in both cases. This commit adds the two new end points, removes the old, single endpoint and updates links to point to the new endpoint.
2020-10-15 13:15:22 +01:00
endpoint,
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
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
_expected_status=404,
)
Allow users with new broadcast permissions access to routes Added two new permissions - `create_broadcasts` and `approve_broadcasts`. These new permissions get added to the `has_permissions` decorator of the broadcast routes to allow the routes to be accessed with either the old permissions on the new ones while we switch over. We were using the `send_messages` permission for the broadcast routes. By having two new permissions we can allow a more granular control of these routes.
2021-06-17 18:03:58 +01:00
@pytest.mark.parametrize('user', (
create_active_user_create_broadcasts_permissions(),
create_active_user_approve_broadcasts_permissions(),
Re-name and re-order some view broadcast tests This tries to make the naming slightly more consistent and groups together tests for the same thing.
2021-07-09 09:33:40 +01:00
create_platform_admin_user(),
Allow users with new broadcast permissions access to routes Added two new permissions - `create_broadcasts` and `approve_broadcasts`. These new permissions get added to the `has_permissions` decorator of the broadcast routes to allow the routes to be accessed with either the old permissions on the new ones while we switch over. We were using the `send_messages` permission for the broadcast routes. By having two new permissions we can allow a more granular control of these routes.
2021-06-17 18:03:58 +01:00
))
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 test_cancel_broadcast(
client_request,
service_one,
Add a confirmation step to cancelling a broadcast It’s an irreversible action if you do click it, so it feels like an ‘Are you sure?’ step is sensible. Follows the same pattern for deleting templates, etc.
2020-07-20 09:27:44 +01:00
mock_get_live_broadcast_message,
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
mock_update_broadcast_message_status,
fake_uuid,
Allow users with new broadcast permissions access to routes Added two new permissions - `create_broadcasts` and `approve_broadcasts`. These new permissions get added to the `has_permissions` decorator of the broadcast routes to allow the routes to be accessed with either the old permissions on the new ones while we switch over. We were using the `send_messages` permission for the broadcast routes. By having two new permissions we can allow a more granular control of these routes.
2021-06-17 18:03:58 +01:00
user,
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
):
Allow platform admins to cancel broadcasts. Do not allow platform admins to: - create broadcasts - approve broadcasts - reject broadcasts that is, unless they have a send_messages permission for a given service. This is so platform admins have the minimum permissions necessary to cancel a broadcast that might have been sent out accidentally.
2021-04-06 15:08:47 +01:00
"""
users with 'send_messages' permissions and platform admins should be able to cancel broadcasts.
"""
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
service_one['permissions'] += ['broadcast']
Allow platform admins to cancel broadcasts. Do not allow platform admins to: - create broadcasts - approve broadcasts - reject broadcasts that is, unless they have a send_messages permission for a given service. This is so platform admins have the minimum permissions necessary to cancel a broadcast that might have been sent out accidentally.
2021-04-06 15:08:47 +01:00
Allow users with new broadcast permissions access to routes Added two new permissions - `create_broadcasts` and `approve_broadcasts`. These new permissions get added to the `has_permissions` decorator of the broadcast routes to allow the routes to be accessed with either the old permissions on the new ones while we switch over. We were using the `send_messages` permission for the broadcast routes. By having two new permissions we can allow a more granular control of these routes.
2021-06-17 18:03:58 +01:00
client_request.login(user)
Add a confirmation step to cancelling a broadcast It’s an irreversible action if you do click it, so it feels like an ‘Are you sure?’ step is sensible. Follows the same pattern for deleting templates, etc.
2020-07-20 09:27:44 +01:00
page = client_request.get(
'.cancel_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
assert normalize_spaces(page.select_one('.banner-dangerous').text) == (
'Are you sure you want to stop this broadcast now? '
'Yes, stop broadcasting'
)
form = page.select_one('form')
assert form['method'] == 'post'
assert 'action' not in form
assert normalize_spaces(form.select_one('button[type=submit]').text) == (
'Yes, stop broadcasting'
)
assert mock_update_broadcast_message_status.called is False
assert url_for(
'.cancel_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
) not in page
Allow users with new broadcast permissions access to routes Added two new permissions - `create_broadcasts` and `approve_broadcasts`. These new permissions get added to the `has_permissions` decorator of the broadcast routes to allow the routes to be accessed with either the old permissions on the new ones while we switch over. We were using the `send_messages` permission for the broadcast routes. By having two new permissions we can allow a more granular control of these routes.
2021-06-17 18:03:58 +01:00
@pytest.mark.parametrize('user', [
create_platform_admin_user(),
create_active_user_create_broadcasts_permissions(),
create_active_user_approve_broadcasts_permissions(),
])
Add a confirmation step to cancelling a broadcast It’s an irreversible action if you do click it, so it feels like an ‘Are you sure?’ step is sensible. Follows the same pattern for deleting templates, etc.
2020-07-20 09:27:44 +01:00
def test_confirm_cancel_broadcast(
client_request,
service_one,
mock_get_live_broadcast_message,
mock_update_broadcast_message_status,
fake_uuid,
Allow users with new broadcast permissions access to routes Added two new permissions - `create_broadcasts` and `approve_broadcasts`. These new permissions get added to the `has_permissions` decorator of the broadcast routes to allow the routes to be accessed with either the old permissions on the new ones while we switch over. We were using the `send_messages` permission for the broadcast routes. By having two new permissions we can allow a more granular control of these routes.
2021-06-17 18:03:58 +01:00
user,
Add a confirmation step to cancelling a broadcast It’s an irreversible action if you do click it, so it feels like an ‘Are you sure?’ step is sensible. Follows the same pattern for deleting templates, etc.
2020-07-20 09:27:44 +01:00
):
Allow platform admins to cancel broadcasts. Do not allow platform admins to: - create broadcasts - approve broadcasts - reject broadcasts that is, unless they have a send_messages permission for a given service. This is so platform admins have the minimum permissions necessary to cancel a broadcast that might have been sent out accidentally.
2021-04-06 15:08:47 +01:00
"""
Allow users with new broadcast permissions access to routes Added two new permissions - `create_broadcasts` and `approve_broadcasts`. These new permissions get added to the `has_permissions` decorator of the broadcast routes to allow the routes to be accessed with either the old permissions on the new ones while we switch over. We were using the `send_messages` permission for the broadcast routes. By having two new permissions we can allow a more granular control of these routes.
2021-06-17 18:03:58 +01:00
Platform admins and users with any of the broadcast permissions can cancel broadcasts.
Allow platform admins to cancel broadcasts. Do not allow platform admins to: - create broadcasts - approve broadcasts - reject broadcasts that is, unless they have a send_messages permission for a given service. This is so platform admins have the minimum permissions necessary to cancel a broadcast that might have been sent out accidentally.
2021-04-06 15:08:47 +01:00
"""
Add a confirmation step to cancelling a broadcast It’s an irreversible action if you do click it, so it feels like an ‘Are you sure?’ step is sensible. Follows the same pattern for deleting templates, etc.
2020-07-20 09:27:44 +01:00
service_one['permissions'] += ['broadcast']
Allow platform admins to cancel broadcasts. Do not allow platform admins to: - create broadcasts - approve broadcasts - reject broadcasts that is, unless they have a send_messages permission for a given service. This is so platform admins have the minimum permissions necessary to cancel a broadcast that might have been sent out accidentally.
2021-04-06 15:08:47 +01:00
Allow users with new broadcast permissions access to routes Added two new permissions - `create_broadcasts` and `approve_broadcasts`. These new permissions get added to the `has_permissions` decorator of the broadcast routes to allow the routes to be accessed with either the old permissions on the new ones while we switch over. We were using the `send_messages` permission for the broadcast routes. By having two new permissions we can allow a more granular control of these routes.
2021-06-17 18:03:58 +01:00
client_request.login(user)
Allow platform admins to cancel broadcasts. Do not allow platform admins to: - create broadcasts - approve broadcasts - reject broadcasts that is, unless they have a send_messages permission for a given service. This is so platform admins have the minimum permissions necessary to cancel a broadcast that might have been sent out accidentally.
2021-04-06 15:08:47 +01:00
Add a confirmation step to cancelling a broadcast It’s an irreversible action if you do click it, so it feels like an ‘Are you sure?’ step is sensible. Follows the same pattern for deleting templates, etc.
2020-07-20 09:27:44 +01:00
client_request.post(
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
'.cancel_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
_expected_redirect=url_for(
Ensure correct selected nav item on broadcast page Once a broadcast has been submitted for approval it either lives on the ‘Current alerts’ or ‘Previous alerts’ page, depending on where it is in its lifecycle. Therefore when clicking into a broadcast from one of those pages the same navigation item should remain selected. Because we select the navigation items based on the request endpoint, this means we need an endpoint for each navigation page, even if the content of the pages will be the same in both cases. This commit adds the two new end points, removes the old, single endpoint and updates links to point to the new endpoint.
2020-10-15 13:15:22 +01:00
'.view_previous_broadcast',
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
service_id=SERVICE_ONE_ID,
Redirect to ‘view’ page after cancelling This is better confirmation of your action than the dashboard, because everything will stay the same except the thing you’ve just done.
2020-07-10 14:22:06 +01:00
broadcast_message_id=fake_uuid,
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
_external=True,
),
Add a confirmation step to cancelling a broadcast It’s an irreversible action if you do click it, so it feels like an ‘Are you sure?’ step is sensible. Follows the same pattern for deleting templates, etc.
2020-07-20 09:27:44 +01:00
)
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
mock_update_broadcast_message_status.assert_called_once_with(
'cancelled',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
)
Add a confirmation step to cancelling a broadcast It’s an irreversible action if you do click it, so it feels like an ‘Are you sure?’ step is sensible. Follows the same pattern for deleting templates, etc.
2020-07-20 09:27:44 +01:00
@pytest.mark.parametrize('method', ('post', 'get'))
def test_cant_cancel_broadcast_in_a_different_state(
client_request,
service_one,
mock_get_draft_broadcast_message,
mock_update_broadcast_message_status,
fake_uuid,
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
active_user_create_broadcasts_permission,
Add a confirmation step to cancelling a broadcast It’s an irreversible action if you do click it, so it feels like an ‘Are you sure?’ step is sensible. Follows the same pattern for deleting templates, etc.
2020-07-20 09:27:44 +01:00
method,
):
service_one['permissions'] += ['broadcast']
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
client_request.login(active_user_create_broadcasts_permission)
Add a confirmation step to cancelling a broadcast It’s an irreversible action if you do click it, so it feels like an ‘Are you sure?’ step is sensible. Follows the same pattern for deleting templates, etc.
2020-07-20 09:27:44 +01:00
getattr(client_request, method)(
'.cancel_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
_expected_redirect=url_for(
Ensure correct selected nav item on broadcast page Once a broadcast has been submitted for approval it either lives on the ‘Current alerts’ or ‘Previous alerts’ page, depending on where it is in its lifecycle. Therefore when clicking into a broadcast from one of those pages the same navigation item should remain selected. Because we select the navigation items based on the request endpoint, this means we need an endpoint for each navigation page, even if the content of the pages will be the same in both cases. This commit adds the two new end points, removes the old, single endpoint and updates links to point to the new endpoint.
2020-10-15 13:15:22 +01:00
'.view_current_broadcast',
Add a confirmation step to cancelling a broadcast It’s an irreversible action if you do click it, so it feels like an ‘Are you sure?’ step is sensible. Follows the same pattern for deleting templates, etc.
2020-07-20 09:27:44 +01:00
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
_external=True,
),
)
assert mock_update_broadcast_message_status.called is False
Reference in New Issue Copy Permalink