darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-08-18 13:39:41 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
dfcddb757ebb0c96b3de9725ecd6cb9b2a87cf03
notifications-admin/app/main/views/broadcast.py

159 lines
5.3 KiB
Python
Raw Normal View History

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 flask import abort, redirect, render_template, request, url_for
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
from app import current_service
from app.main import main
Add search form There can be lots of areas in a library, for example local councils. So when there is, let’s allow people to do the find-as-you-type thing we support in lots of other places.
2020-07-06 10:53:16 +01:00
from app.main.forms import BroadcastAreaForm, SearchByNameForm
Add broadcasts to the dashboard Shows current and previous broadcasts. Does not add a page for viewing an individual broadcast. Broadcasts are split into live and previous. Draft broadcasts are excluded from the dashboard.
2020-07-09 15:48:56 +01:00
from app.models.broadcast_message import BroadcastMessage, BroadcastMessages
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
from app.utils import service_has_permission, user_has_permissions
Add a dashboard for broadcast services This is just a placeholder for now
2020-07-08 11:34:16 +01:00
@main.route('/services/<uuid:service_id>/broadcast-dashboard')
@user_has_permissions()
@service_has_permission('broadcast')
def broadcast_dashboard(service_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
broadcast_messages = BroadcastMessages(service_id)
Add a dashboard for broadcast services This is just a placeholder for now
2020-07-08 11:34:16 +01:00
return render_template(
'views/broadcast/dashboard.html',
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
live_broadcasts=broadcast_messages.with_status('broadcasting'),
previous_broadcasts=broadcast_messages.with_status('cancelled', 'completed'),
Add a dashboard for broadcast services This is just a placeholder for now
2020-07-08 11:34:16 +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
@main.route('/services/<uuid:service_id>/new-broadcast/<uuid:template_id>')
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
@user_has_permissions('send_messages')
@service_has_permission('broadcast')
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 broadcast(service_id, template_id):
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
return redirect(url_for(
'.preview_broadcast_areas',
service_id=current_service.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=BroadcastMessage.create(
service_id=service_id,
template_id=template_id,
).id,
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
@main.route('/services/<uuid:service_id>/broadcast/<uuid:broadcast_message_id>/areas')
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
@user_has_permissions('send_messages')
@service_has_permission('broadcast')
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 preview_broadcast_areas(service_id, broadcast_message_id):
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
return render_template(
'views/broadcast/preview-areas.html',
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=BroadcastMessage.from_id(
broadcast_message_id,
service_id=current_service.id,
),
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
@main.route('/services/<uuid:service_id>/broadcast/<uuid:broadcast_message_id>/libraries')
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
@user_has_permissions('send_messages')
@service_has_permission('broadcast')
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 choose_broadcast_library(service_id, broadcast_message_id):
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
return render_template(
'views/broadcast/libraries.html',
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
libraries=BroadcastMessage.libraries,
broadcast_message_id=broadcast_message_id,
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
@main.route(
'/services/<uuid:service_id>/broadcast/<uuid:broadcast_message_id>/libraries/<library_slug>',
methods=['GET', 'POST'],
)
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
@user_has_permissions('send_messages')
@service_has_permission('broadcast')
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 choose_broadcast_area(service_id, broadcast_message_id, library_slug):
broadcast_message = BroadcastMessage.from_id(
broadcast_message_id,
service_id=current_service.id,
)
library = BroadcastMessage.libraries.get(library_slug)
Add a form for choosing areas Picking multiple areas at once definitely feels like a need, so let’s make them checkboxes.
2020-07-06 10:53:16 +01:00
form = BroadcastAreaForm.from_library(library)
if form.validate_on_submit():
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.add_areas(*form.areas.data)
Add a form for choosing areas Picking multiple areas at once definitely feels like a need, so let’s make them checkboxes.
2020-07-06 10:53:16 +01:00
return redirect(url_for(
'.preview_broadcast_areas',
service_id=current_service.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=broadcast_message.id,
Add a form for choosing areas Picking multiple areas at once definitely feels like a need, so let’s make them checkboxes.
2020-07-06 10:53: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
return render_template(
'views/broadcast/areas.html',
Add a form for choosing areas Picking multiple areas at once definitely feels like a need, so let’s make them checkboxes.
2020-07-06 10:53:16 +01:00
form=form,
Add search form There can be lots of areas in a library, for example local councils. So when there is, let’s allow people to do the find-as-you-type thing we support in lots of other places.
2020-07-06 10:53:16 +01:00
search_form=SearchByNameForm(),
show_search_form=(len(form.areas.choices) > 7),
Add a form for choosing areas Picking multiple areas at once definitely feels like a need, so let’s make them checkboxes.
2020-07-06 10:53:16 +01:00
page_title=library.name,
Fix back link
2020-07-10 09:25:17 +01:00
broadcast_message=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
)
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
@main.route('/services/<uuid:service_id>/broadcast/<uuid:broadcast_message_id>/remove/<area_slug>')
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
@user_has_permissions('send_messages')
@service_has_permission('broadcast')
Make the broadcast flow talk to the API This commit removes the code the puts areas into the session and instead creates and then updates a draft broadcast in the database. This is so we can avoid session-related bugs, and potentially having a large session when we start adding personalisation etc. Once a broadcast is ready to go it is set to `broadcasting` straight away with no approval. We’ll revisit this as we learn more about how users might want to manage who can create and approve broadcasts. The tests are a bit light in terms of checking what’s on the page, but clicking through the pages is probably good enough for now.
2020-07-09 10:33:50 +01:00
def remove_broadcast_area(service_id, broadcast_message_id, area_slug):
BroadcastMessage.from_id(
broadcast_message_id,
service_id=current_service.id,
).remove_area(
area_slug
)
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
return redirect(url_for(
'.preview_broadcast_areas',
service_id=current_service.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=broadcast_message_id,
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
@main.route(
'/services/<uuid:service_id>/broadcast/<uuid:broadcast_message_id>/preview',
methods=['GET', 'POST'],
)
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
@user_has_permissions('send_messages')
@service_has_permission('broadcast')
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 preview_broadcast_message(service_id, broadcast_message_id):
broadcast_message = BroadcastMessage.from_id(
broadcast_message_id,
service_id=current_service.id,
)
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
if request.method == 'POST':
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.start_broadcast()
return redirect(url_for(
'.broadcast_dashboard',
service_id=current_service.id,
))
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
return render_template(
'views/broadcast/preview-message.html',
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=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
)
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
@main.route('/services/<uuid:service_id>/broadcast/<uuid:broadcast_message_id>')
@user_has_permissions('send_messages')
@service_has_permission('broadcast')
def view_broadcast_message(service_id, broadcast_message_id):
broadcast_message = BroadcastMessage.from_id(
broadcast_message_id,
service_id=current_service.id,
)
if broadcast_message.status == 'draft':
abort(404)
return render_template(
'views/broadcast/view-message.html',
broadcast_message=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
@main.route('/services/<uuid:service_id>/broadcast/<uuid:broadcast_message_id>/cancel')
@user_has_permissions('send_messages')
@service_has_permission('broadcast')
def cancel_broadcast_message(service_id, broadcast_message_id):
BroadcastMessage.from_id(
broadcast_message_id,
service_id=current_service.id,
).cancel_broadcast()
return 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=current_service.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=broadcast_message_id,
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
))
Reference in New Issue Copy Permalink