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

1211 lines
34 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
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
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
from tests.conftest import SERVICE_ONE_ID, 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,
),
(
'.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,
),
(
'.view_broadcast_message', {'broadcast_message_id': sample_uuid},
403, 403,
),
(
'.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
)
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', (
(
'.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,
),
(
'.cancel_broadcast_message', {'broadcast_message_id': sample_uuid},
403, 403,
),
))
def test_broadcast_pages_403_for_user_without_permission(
mocker,
client_request,
service_one,
active_user_view_permissions,
endpoint,
extra_args,
expected_get_status,
expected_post_status,
):
service_one['permissions'] += ['broadcast']
mocker.patch('app.user_api_client.get_user', return_value=active_user_view_permissions)
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
)
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
@pytest.mark.parametrize('step_index, expected_link_text, expected_link_href', (
(1, 'Continue', partial(url_for, '.broadcast_tour', step_index=2)),
(2, 'Continue', partial(url_for, '.broadcast_tour', step_index=3)),
(3, 'Continue', partial(url_for, '.broadcast_tour', step_index=4)),
Improve pacing and sequence of information in the broadcast tour This commit refines which information we show on each page. Specifically we’re - adding some wording (‘at exactly the same time’) to try to communicate the immediacy - giving the ‘loud noises’ message it’s own screen to really draw attention to it - moving the ‘no phone numbers bit’ later in the journey, and experimenting with explaining why that is, to make it clearer how it’s different to a text message
2020-08-25 11:31:25 +01:00
(4, 'Continue', partial(url_for, '.broadcast_tour', step_index=5)),
(5, 'Continue to dashboard', 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,
step_index,
expected_link_text,
expected_link_href,
):
service_one['permissions'] += ['broadcast']
page = client_request.get(
'.broadcast_tour',
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)
@pytest.mark.parametrize('step_index', (
pytest.param(1, marks=pytest.mark.xfail),
pytest.param(2, marks=pytest.mark.xfail),
pytest.param(3, marks=pytest.mark.xfail),
Improve pacing and sequence of information in the broadcast tour This commit refines which information we show on each page. Specifically we’re - adding some wording (‘at exactly the same time’) to try to communicate the immediacy - giving the ‘loud noises’ message it’s own screen to really draw attention to it - moving the ‘no phone numbers bit’ later in the journey, and experimenting with explaining why that is, to make it clearer how it’s different to a text message
2020-08-25 11:31:25 +01:00
pytest.param(4, marks=pytest.mark.xfail),
5,
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_4_shows_service_name(
client_request,
service_one,
step_index,
):
service_one['permissions'] += ['broadcast']
page = client_request.get(
'.broadcast_tour',
service_id=SERVICE_ONE_ID,
step_index=step_index,
)
assert normalize_spaces(page.select_one('.navigation-service').text) == (
'service one Training'
)
Improve pacing and sequence of information in the broadcast tour This commit refines which information we show on each page. Specifically we’re - adding some wording (‘at exactly the same time’) to try to communicate the immediacy - giving the ‘loud noises’ message it’s own screen to really draw attention to it - moving the ‘no phone numbers bit’ later in the journey, and experimenting with explaining why that is, to make it clearer how it’s different to a text message
2020-08-25 11:31:25 +01:00
@pytest.mark.parametrize('step_index', (0, 6))
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,
step_index,
):
service_one['permissions'] += ['broadcast']
client_request.get(
'.broadcast_tour',
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,
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
active_user_view_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
mock_get_no_broadcast_messages,
Add a tour for users new to broadcast services This is an initial, prototype-quality attempt at introducing some kind of tour for users new to broadcasting. A lot of the users we’re speaking to don’t have a good concept of what broadcasting means, which is causing usability problems down the line. We did a similar thing in the early days of Notify to explain the concept of message templates and personalisation.
2020-08-03 13:37:34 +01:00
mock_get_service_templates_when_no_templates_exist,
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
):
service_one['permissions'] += ['broadcast']
page = client_request.get(
'.broadcast_dashboard',
service_id=SERVICE_ONE_ID,
)
assert [
normalize_spaces(row.text) for row in page.select('tbody tr .table-empty-message')
] == [
Replace ‘broadcast’ with ‘alert’ on dashboard We’re moving away from ‘broadcast’ as a noun, so this commit updates the dashboard to be in line with changes in other PRs.
2020-08-24 12:04:06 +01:00
'You do not have any live alerts at the moment',
'You do not have any alerts waiting for approval',
'You do not have any previous 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
]
@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,
Add a tour for users new to broadcast services This is an initial, prototype-quality attempt at introducing some kind of tour for users new to broadcasting. A lot of the users we’re speaking to don’t have a good concept of what broadcasting means, which is causing usability problems down the line. We did a similar thing in the early days of Notify to explain the concept of message templates and personalisation.
2020-08-03 13:37:34 +01:00
mock_get_service_templates,
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']
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
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
assert normalize_spaces(page.select('main h2')[0].text) == (
Replace ‘broadcast’ with ‘alert’ on dashboard We’re moving away from ‘broadcast’ as a noun, so this commit updates the dashboard to be in line with changes in other PRs.
2020-08-24 12:04:06 +01:00
'Live alerts'
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 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 [
normalize_spaces(row.text) for row in page.select('table')[0].select('tbody tr')
] == [
fix tests
2020-07-22 15:15:23 +01:00
'Example template To England and Scotland Live until tomorrow at 2:20am',
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
]
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
assert normalize_spaces(page.select('main h2')[1].text) == (
fix tests
2020-07-22 15:15:23 +01:00
'Waiting for approval'
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 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 [
normalize_spaces(row.text) for row in page.select('table')[1].select('tbody tr')
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
] == [
fix tests
2020-07-22 15:15:23 +01:00
'Example template To England and Scotland Prepared by Test User',
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
]
assert normalize_spaces(page.select('main h2')[2].text) == (
Replace ‘broadcast’ with ‘alert’ on dashboard We’re moving away from ‘broadcast’ as a noun, so this commit updates the dashboard to be in line with changes in other PRs.
2020-08-24 12:04:06 +01:00
'Previous alerts'
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
)
assert [
normalize_spaces(row.text) for row in page.select('table')[2].select('tbody tr')
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
] == [
'Example template To England and Scotland Stopped 10 February at 2:20am',
Implement sorting Shows the broadcasts with the longest time still to live at the top. At the moment this will be the same as the newest broadcasts, so we may want to revisit this sort order when we have broadcasts of variable duration. For no-longer-live broadcasts we show the most-recently-finished at the top, whether it finished naturally or was cancelled.
2020-07-10 09:26:47 +01:00
'Example template To England and Scotland Finished yesterday at 8:20pm',
Add broadcasts to the dashboard Shows current and previous broadcasts. Does not add a page for viewing an individual broadcast. Broadcasts are split into live and previous. Draft broadcasts are excluded from the dashboard.
2020-07-09 15:48:56 +01:00
]
Add a dashboard for broadcast services This is just a placeholder for now
2020-07-08 11:34:16 +01: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
@freeze_time('2020-02-20 02:20')
def test_broadcast_dashboard_json(
logged_in_client,
service_one,
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
active_user_view_permissions,
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
mock_get_broadcast_messages,
):
service_one['permissions'] += ['broadcast']
response = logged_in_client.get(url_for(
'.broadcast_dashboard_updates',
service_id=SERVICE_ONE_ID,
))
assert response.status_code == 200
json_response = json.loads(response.get_data(as_text=True))
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
assert json_response.keys() == {
'pending_approval_broadcasts',
'live_broadcasts',
'previous_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
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
assert 'Prepared by Test User' in json_response['pending_approval_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
assert 'Live until tomorrow at 2:20am' in json_response['live_broadcasts']
assert 'Finished yesterday at 8:20pm' in json_response['previous_broadcasts']
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,
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']
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(
'.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,
),
),
def test_preview_broadcast_areas_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_get_draft_broadcast_message,
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']
client_request.get(
'.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
)
def test_choose_broadcast_library_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,
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']
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)
for title in page.select('.file-list-filename-large')
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
] == [
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
'Countries',
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
'Local authorities',
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
]
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) == (
Always show 4 items in the example list If a library has lots of items then the first 3 should be shown, with a count of how many more there are, for a total of 4 list items: > a, b, c, and 23 more If the library only has 4 items then all 4 should be shown, with consistent use of conjunction and Oxford comma[1]: > a, b, c, and d This keeps the lengths of the examples nice and consistent. 1. We use an Oxford comma because it helps disambiguate when an area itself has a comma or ‘and’ in it, for example ‘Armagh City, Banbridge and Craigavon’
2020-08-12 12:17:40 +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
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,
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']
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,
):
service_one['permissions'] += ['broadcast']
page = client_request.get(
'.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='wd20-lad20',
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,
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='wd20-lad20',
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')
]
assert len(choices) == 379
assert choices[:2] == [
(
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
partial_url_for(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
'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
partial_url_for(area_slug='lad20-S12000034'),
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
'Aberdeenshire',
),
]
assert 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
partial_url_for(area_slug='lad20-E06000014'),
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
'York',
),
]
def test_choose_broadcast_sub_area_page(
client_request,
service_one,
mock_get_draft_broadcast_message,
fake_uuid,
):
service_one['permissions'] += ['broadcast']
page = client_request.get(
'main.choose_broadcast_sub_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='wd20-lad20',
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]")
assert live_search['data-targets'] == '.govuk-checkboxes__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
choices = [
(
choice.select_one('input')['value'],
normalize_spaces(choice.select_one('label').text),
)
for choice in page.select('form[method=post] .govuk-checkboxes__item')
]
assert choices[:3] == [
('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
]
assert 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
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,
):
service_one['permissions'] += ['broadcast']
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
}
)
mock_update_broadcast_message.assert_called_once_with(
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
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-S92000003', '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
},
)
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
@pytest.mark.parametrize('post_data, expected_selected', (
({
'select_all': 'y',
'areas': [
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',
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
]
}, [
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
'lad20-S12000033',
# wd20-S13002845 is ignored because the user chose ‘Select all…’
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
]),
({
'areas': [
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',
'wd20-S13002836',
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
]
}, [
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',
'wd20-S13002836',
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_add_broadcast_sub_area(
client_request,
service_one,
mock_get_draft_broadcast_message,
mock_update_broadcast_message,
fake_uuid,
post_data,
expected_selected,
):
service_one['permissions'] += ['broadcast']
client_request.post(
'.choose_broadcast_sub_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='wd20-lad20',
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,
)
mock_update_broadcast_message.assert_called_once_with(
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
data={
'areas': [
# These two areas are on the broadcast already
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',
'ctry19-S92000003',
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
] + expected_selected
},
)
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,
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']
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
)
mock_update_broadcast_message.assert_called_once_with(
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
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-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,
mock_get_broadcast_template,
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
):
service_one['permissions'] += ['broadcast']
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',
]
assert normalize_spaces(
page.select_one('.broadcast-message-wrapper').text
) == (
'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
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
@freeze_time('2020-02-02 02:02:02')
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_get_broadcast_template,
mock_update_broadcast_message_status,
fake_uuid,
):
service_one['permissions'] += ['broadcast']
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(
'main.view_broadcast_message',
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
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
@pytest.mark.parametrize('extra_fields, expected_paragraphs', (
({
'status': 'broadcasting',
'finishes_at': '2020-02-23T23:23:23.000000',
}, [
'Created by Alice and approved by Bob.',
'Started broadcasting on 20 February at 8:20pm.',
'Live until tomorrow at 11:23pm Stop broadcast early',
]),
({
'status': 'broadcasting',
'finishes_at': '2020-02-22T22:20:20.000000', # 2 mins before now()
}, [
'Created by Alice and approved by Bob.',
'Started broadcasting on 20 February at 8:20pm.',
'Finished broadcasting today at 10:20pm.',
]),
({
'status': 'finished',
'finishes_at': '2020-02-21T21:21:21.000000',
}, [
'Created by Alice and approved by Bob.',
'Started broadcasting on 20 February at 8:20pm.',
'Finished broadcasting yesterday at 9:21pm.',
]),
({
'status': 'cancelled',
'cancelled_by_id': sample_uuid,
'cancelled_at': '2020-02-21T21:21:21.000000',
}, [
'Created by Alice and approved by Bob.',
'Started broadcasting on 20 February at 8:20pm.',
'Stopped by Carol yesterday at 9:21pm.',
]),
))
@freeze_time('2020-02-22T22:22:22.000000')
def test_view_broadcast_message_page(
mocker,
client_request,
service_one,
active_user_with_permissions,
mock_get_broadcast_template,
fake_uuid,
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,
created_by_id=fake_uuid,
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=[
active_user_with_permissions,
user_json(name='Alice'),
user_json(name='Bob'),
user_json(name='Carol'),
])
service_one['permissions'] += ['broadcast']
page = client_request.get(
'.view_broadcast_message',
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
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')
def test_view_pending_broadcast(
mocker,
client_request,
service_one,
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
active_user_with_permissions,
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_get_broadcast_template,
fake_uuid,
):
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,
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',
),
)
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=[
active_user_with_permissions, # Current user
user_json(id_=uuid.uuid4()), # User who created 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_one['permissions'] += ['broadcast']
page = client_request.get(
'.view_broadcast_message',
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
'Test User wants to broadcast Example template '
'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
)
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
)
@freeze_time('2020-02-22T22:22:22.000000')
def test_cant_approve_own_broadcast(
mocker,
client_request,
service_one,
active_user_with_permissions,
mock_get_broadcast_template,
fake_uuid,
):
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['restricted'] = 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
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',
),
)
mocker.patch('app.user_api_client.get_user', side_effect=[
active_user_with_permissions, # Current user
active_user_with_permissions, # User who created broadcast (the same)
])
service_one['permissions'] += ['broadcast']
page = client_request.get(
'.view_broadcast_message',
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
) == (
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
'You need another member of your team to approve your 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
)
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 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
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')
assert link.text == 'Withdraw this alert'
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')
def test_can_approve_own_broadcast_in_trial_mode(
mocker,
client_request,
service_one,
active_user_with_permissions,
mock_get_broadcast_template,
fake_uuid,
):
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',
),
)
mocker.patch('app.user_api_client.get_user', side_effect=[
active_user_with_permissions, # Current user
active_user_with_permissions, # User who created broadcast (the same)
])
service_one['permissions'] += ['broadcast']
page = client_request.get(
'.view_broadcast_message',
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)
) == (
'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 '
'Cancel 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
link = page.select_one('.banner 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 == 'Cancel 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')
def test_view_only_user_cant_approve_broadcast(
mocker,
client_request,
service_one,
active_user_with_permissions,
active_user_view_permissions,
mock_get_broadcast_template,
fake_uuid,
):
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',
),
)
mocker.patch('app.user_api_client.get_user', side_effect=[
active_user_view_permissions, # Current user
active_user_with_permissions, # User who created broadcast
])
service_one['permissions'] += ['broadcast']
page = client_request.get(
'.view_broadcast_message',
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')
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
@pytest.mark.parametrize('initial_status, expected_approval', (
('draft', False,),
('pending-approval', True),
('rejected', False),
('broadcasting', False),
('cancelled', False),
))
@freeze_time('2020-02-22T22:22:22.000000')
def test_approve_broadcast(
mocker,
client_request,
service_one,
mock_get_broadcast_template,
fake_uuid,
mock_update_broadcast_message,
mock_update_broadcast_message_status,
initial_status,
expected_approval,
):
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']
client_request.post(
'.view_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
_expected_redirect=url_for(
'.view_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
_external=True,
)
)
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',
Remove choice of ‘End time’ from broadcast journey Since we added the end time picker: - we have discovered that broadcasts can’t be longer than 24h - we have observed that most users confuse picking the end time for scheduling the message, or don’t understand exactly what it means for the broadcast to ‘end’ - we’ve developed the concept of ‘training mode’, which you should be going through before sending a real broadcast We also think that, for most scenarios, you won’t necessarily know when a broadcast should end at the time of starting it because the cause of the danger is not within your control. So giving you control of the end time before the broadcast has even been approved is a confusing distraction. Having to pick a time at all also makes the whole process feel more planned and less immediate. Whereas in reality all the phones in the area will be getting the message in seconds. It’s only people coming into the area later to whom the ‘ongoing’ aspect of the broadcast applies. The best place to explain what’s happening with the phones is at the approval stage and once you’ve sent your first (training mode) broadcast. It’s easier to explain what’s happened if it’s in direct response to something you’ve just done. Later on we should add some kind of email reminder after 12 hours to make sure you still want the broadcast live, again after 18 hours, etc. We could let you schedule an end time once the broadcast is live, but don’t think there’s a strong need. Knowing enough that you want to cancel is one thing, but knowing enough to want to cancel but wanting to wait a bit… nah.
2020-08-18 16:36:40 +01:00
'finishes_at': '2020-02-23T22:21:22',
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
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,
mock_get_broadcast_template,
fake_uuid,
mock_update_broadcast_message,
mock_update_broadcast_message_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='pending-approval',
),
)
service_one['permissions'] += ['broadcast']
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,
)
@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,
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']
client_request.get(
'.reject_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
_expected_redirect=url_for(
'.view_broadcast_message',
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
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,
):
service_one['permissions'] += ['broadcast']
client_request.get(
'.view_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
_expected_status=404,
)
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,
mock_get_broadcast_template,
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,
):
service_one['permissions'] += ['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
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
def test_confirm_cancel_broadcast(
client_request,
service_one,
mock_get_live_broadcast_message,
mock_get_broadcast_template,
mock_update_broadcast_message_status,
fake_uuid,
):
service_one['permissions'] += ['broadcast']
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(
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
'.view_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
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,
method,
):
service_one['permissions'] += ['broadcast']
getattr(client_request, method)(
'.cancel_broadcast_message',
service_id=SERVICE_ONE_ID,
broadcast_message_id=fake_uuid,
_expected_redirect=url_for(
'.view_broadcast_message',
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