darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-08-15 15:28:50 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
2bb460fff25a377ada82dfd4aa4deabec0c61250
notifications-admin/app/templates/views/broadcast/view-message.html

225 lines
8.8 KiB
HTML
Raw Normal View History

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
{% from "components/back-link/macro.njk" import govukBackLink %}
Add map in details to broadcast view Avoided using `closest` as not supported by IE8-11 https://caniuse.com/#search=closest Used `parentElement` supported by IE9+ https://caniuse.com/#search=parentElement Used `className` as supported by IE9+ https://caniuse.com/#search=className Also rearranged the javascript for maps such that figuring out the polygon array is done first and then the time when we need to have the details component open before closing it again is kept to minimum
2020-09-03 10:55:01 +01:00
{% from "components/details/macro.njk" import govukDetails %}
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 "components/form.html" import form_wrapper %}
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
{% from "components/banner.html" import banner %}
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 "components/page-header.html" import page_header %}
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
{% from "components/page-footer.html" import page_footer %}
Add estimated areas for non-visual users Since the key relies on visual association between the shapes on the maps and the styling of the key, it won’t work for non-visual users. An alternative way of giving them the same information is by providing the size of the area numerically.
2020-09-08 16:35:03 +01:00
{% from "views/broadcast/macros/area-map.html" import map %}
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
{% extends "withnav_template.html" %}
Add map in details to broadcast view Avoided using `closest` as not supported by IE8-11 https://caniuse.com/#search=closest Used `parentElement` supported by IE9+ https://caniuse.com/#search=parentElement Used `className` as supported by IE9+ https://caniuse.com/#search=className Also rearranged the javascript for maps such that figuring out the polygon array is done first and then the time when we need to have the details component open before closing it again is kept to minimum
2020-09-03 10:55:01 +01:00
{% block extra_stylesheets %}
{% include "views/broadcast/partials/area-map-stylesheets.html" %}
{% endblock %}
{% block extra_javascripts %}
{% include "views/broadcast/partials/area-map-javascripts.html" %}
{% endblock %}
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
{% block service_page_title %}
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
{% if broadcast_message.status == 'pending-approval' %}
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
{% if broadcast_message.created_by and broadcast_message.created_by == current_user
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
and current_user.has_permissions('create_broadcasts', 'approve_broadcasts', restrict_admin_usage=True) %}
Display broadcasts without a template At the moment the admin app expects all broadcasts to have a template, and expects the content of the alert to come from the template. This commit makes it so those pages can still get a `Template` instance, but populated with content straight from the `content` field in the database.
2021-01-15 15:11:43 +00:00
{{ broadcast_message.template.name }} is waiting for approval
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
{% elif current_user.has_permissions('approve_broadcasts', restrict_admin_usage=True) %}
Show broadcasts created by the API Broadcasts created by the API are different in that: - they aren’t created by any user, so don’t have a `created_by_id` - they are created instantly, not in steps, so don’t have an `updated_at` time This commit alters the views to account for when these pieces of information aren’t present.
2021-01-27 11:24:22 +00:00
{% if broadcast_message.created_by %}
{{ broadcast_message.created_by.name }}
{% else %}
An API call
{% endif %}
wants to broadcast
Display broadcasts without a template At the moment the admin app expects all broadcasts to have a template, and expects the content of the alert to come from the template. This commit makes it so those pages can still get a `Template` instance, but populated with content straight from the `content` field in the database.
2021-01-15 15:11:43 +00:00
{{ broadcast_message.template.name }}
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
{% else %}
This alert is waiting for approval
{% endif %}
{% else %}
Display broadcasts without a template At the moment the admin app expects all broadcasts to have a template, and expects the content of the alert to come from the template. This commit makes it so those pages can still get a `Template` instance, but populated with content straight from the `content` field in the database.
2021-01-15 15:11:43 +00:00
{{ broadcast_message.template.name }}
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
{% endif %}
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
{% endblock %}
Move back link above main content for straightforward cases This moves the back link to be above the `<main>` tag by making use of the new `backLink` block. This doesn't change the pages which are using a back link as part of the `page_header` macro yet.
2021-07-30 14:42:54 +01:00
{% block backLink %}
Fix back links when viewing a broadcast Where you go back to from a broadcast can now depend on whether it’s a current or previous broadcast.
2020-10-15 13:18:23 +01:00
{{ govukBackLink({ "href": back_link }) }}
Move back link above main content for straightforward cases This moves the back link to be above the `<main>` tag by making use of the new `backLink` block. This doesn't change the pages which are using a back link as part of the `page_header` macro yet.
2021-07-30 14:42:54 +01:00
{% endblock %}
{% block maincolumn_content %}
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
Add page for broadcast in pending state Since we’ll be linking to pending broadcasts from the dashboard, the page needs to be ready to display them. Pending broadcasts lack a few bits of information that live or previous broadcasts have (like the start date for example). So this commit hides the code that displays those bits of information.
2020-07-17 08:07:41 +01:00
{% if broadcast_message.status == 'pending-approval' %}
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
{% if broadcast_message.created_by and broadcast_message.created_by == current_user
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
and current_user.has_permissions('create_broadcasts', 'approve_broadcasts', restrict_admin_usage=True) %}
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
<div class="banner govuk-!-margin-bottom-6">
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
<h1 class="govuk-heading-m govuk-!-margin-bottom-3">
Display broadcasts without a template At the moment the admin app expects all broadcasts to have a template, and expects the content of the alert to come from the template. This commit makes it so those pages can still get a `Template` instance, but populated with content straight from the `content` field in the database.
2021-01-15 15:11:43 +00:00
{{ broadcast_message.template.name }} is waiting for approval
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
</h1>
{% if current_service.live %}
<p class="govuk-body">
You need another member of your team to approve your alert.
</p>
{{ page_footer(
delete_link=url_for('main.reject_broadcast_message', service_id=current_service.id, broadcast_message_id=broadcast_message.id),
Change 'withdraw' to 'discard'
2021-07-05 17:10:35 +01:00
delete_link_text='Discard this alert'
Let people approve own broadcasts in training mode We want to let users learn the system by trying it out. At the moment they can’t explore it fully by themselves because they’re blocked at the point of approving the broadcast, unless they involve in another member of their team. Having to involve another person is friction that will discourage people from exploring. So this adds a button that lets people approve their own broadcasts in trial mode, with some rough-and-ready content that explains training mode and how it would be different to trial mode.
2020-08-21 11:26:02 +01:00
) }}
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
{% elif current_user.has_permissions('approve_broadcasts', restrict_admin_usage=True) %}
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
<p class="govuk-body govuk-!-margin-bottom-3">
When you use a live account you’ll need another member of
your team to approve your alert.
</p>
<details class="govuk-details govuk-!-margin-bottom-0" data-module="govuk-details">
<summary class="govuk-details__summary govuk-clearfix">
Approve your own alert
</summary>
{% call form_wrapper() %}
<p class="govuk-body govuk-!-margin-top-2 govuk-!-margin-bottom-3">
Because you’re in training mode you can approve
your own alerts, to see how it works.
</p>
<p class="govuk-body govuk-!-margin-top-0 govuk-!-margin-bottom-3">
No real alerts will be broadcast to anyone’s phone.
</p>
{{ page_footer(
"Start broadcasting now",
delete_link=url_for('main.reject_broadcast_message', service_id=current_service.id, broadcast_message_id=broadcast_message.id),
Change 'cancel' to 'reject'
2021-07-05 17:22:35 +01:00
delete_link_text='Reject this alert'
Let people approve own broadcasts in training mode We want to let users learn the system by trying it out. At the moment they can’t explore it fully by themselves because they’re blocked at the point of approving the broadcast, unless they involve in another member of their team. Having to involve another person is friction that will discourage people from exploring. So this adds a button that lets people approve their own broadcasts in trial mode, with some rough-and-ready content that explains training mode and how it would be different to trial mode.
2020-08-21 11:26:02 +01:00
) }}
{% endcall %}
</details>
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
{% elif current_user.has_permissions('create_broadcasts', restrict_admin_usage=True) %}
<p class="govuk-body">
You need another member of your team to approve this alert.
</p>
<p class="govuk-body">
This service is in training mode. No real alerts will be sent.
</p>
{{ page_footer(
delete_link=url_for('main.reject_broadcast_message', service_id=current_service.id, broadcast_message_id=broadcast_message.id),
delete_link_text='Discard this alert'
) }}
Let people approve own broadcasts in training mode We want to let users learn the system by trying it out. At the moment they can’t explore it fully by themselves because they’re blocked at the point of approving the broadcast, unless they involve in another member of their team. Having to involve another person is friction that will discourage people from exploring. So this adds a button that lets people approve their own broadcasts in trial mode, with some rough-and-ready content that explains training mode and how it would be different to trial mode.
2020-08-21 11:26:02 +01:00
{% endif %}
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
</div>
Remove check for send_messages permission from broadcast pages The `send_messages` permission has been deprecated for use with broadcast services, so we can drop support for it in the code. We were supporting both the old permissions and new permissions (`create_broadcasts` and `approve_broadcasts`) while we switched people over. This removes `send_messages` from the `user_has_permissions` decorator around the broadcast routes and from the page to view a broadcast and broadcast dashboards. We can now git rid of a lot of the parameterization that was temporarily added to the tests.
2021-07-22 17:12:01 +01:00
{% elif current_user.has_permissions('approve_broadcasts', restrict_admin_usage=True) %}
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
{% call form_wrapper(class="banner govuk-!-margin-bottom-6") %}
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
<h1 class="govuk-heading-m govuk-!-margin-top-0 govuk-!-margin-bottom-3">
Show broadcasts created by the API Broadcasts created by the API are different in that: - they aren’t created by any user, so don’t have a `created_by_id` - they are created instantly, not in steps, so don’t have an `updated_at` time This commit alters the views to account for when these pieces of information aren’t present.
2021-01-27 11:24:22 +00:00
{% if broadcast_message.created_by %}
{{ broadcast_message.created_by.name }}
{% else %}
An API call
{% endif %}
wants to broadcast
Display broadcasts without a template At the moment the admin app expects all broadcasts to have a template, and expects the content of the alert to come from the template. This commit makes it so those pages can still get a `Template` instance, but populated with content straight from the `content` field in the database.
2021-01-15 15:11:43 +00:00
{{ broadcast_message.template.name }}
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
</h1>
Add a confirmation checkbox for live broadcasts We want people to be really sure before sending a live broadcast, not just clicking through the green buttons. This commit adds a checkbox which explains exactly the consequences of what they’re about to do, tailored to the channel they’re on, and the area chosen by the person creating the alert.
2021-05-12 13:26:13 +01:00
{% if current_service.live %}
{{ form.confirm(param_extensions={
'formGroup': {
'classes': 'govuk-!-margin-bottom-4'
}
}) }}
{% else %}
<p class="govuk-body govuk-!-margin-bottom-3">
No phones will get this alert.
</p>
{% endif %}
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
{{ page_footer(
"Start broadcasting now",
delete_link=url_for('main.reject_broadcast_message', service_id=current_service.id, broadcast_message_id=broadcast_message.id),
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
delete_link_text='Reject 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
) }}
{% endcall %}
Change /broadcast/view-message.html page to work with both permissions The buttons and links on this page now work with the original permissions and the two new broadcast permissions. Since the new broadcast permissions have the effect of splitting the `send_messages` permission this means that additional sections of if/else logic were required.
2021-06-29 17:34:29 +01:00
{% elif current_user.has_permissions('create_broadcasts', restrict_admin_usage=True) %}
<div class="banner govuk-!-margin-bottom-6">
<h1 class="govuk-heading-m govuk-!-margin-bottom-3">This alert is waiting for approval</h1>
<p class="govuk-body">
Another member of your team needs to approve this alert.
</p>
{% if not current_service.live %}
<p class="govuk-body">
This service is in training mode. No real alerts will be sent.
</p>
{% endif %}
{{ page_footer(
delete_link=url_for('main.reject_broadcast_message', service_id=current_service.id, broadcast_message_id=broadcast_message.id),
delete_link_text='Reject this alert'
) }}
</div>
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
{% else %}
<div class="banner govuk-!-margin-bottom-6">
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
<h1 class="govuk-heading-m govuk-!-margin-bottom-3">This alert is waiting for approval</h1>
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
<p class="govuk-body">
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 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
</p>
</div>
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
{% endif %}
Add page for broadcast in pending state Since we’ll be linking to pending broadcasts from the dashboard, the page needs to be ready to display them. Pending broadcasts lack a few bits of information that live or previous broadcasts have (like the start date for example). So this commit hides the code that displays those bits of information.
2020-07-17 08:07:41 +01:00
{% else %}
Display broadcasts without a template At the moment the admin app expects all broadcasts to have a template, and expects the content of the alert to come from the template. This commit makes it so those pages can still get a `Template` instance, but populated with content straight from the `content` field in the database.
2021-01-15 15:11:43 +00:00
{{ page_header(broadcast_message.template.name) }}
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
Move end time to bottom of page End time is less important than the status of the broadcast, or when it was started (eg when it was received by most people in the area).
2020-10-14 14:05:14 +01:00
{% if broadcast_message.status == 'broadcasting' %}
Use live indicator on individual broadcast page So the view of an individual broadcast feel consistent when coming from the dashboard.
2020-10-14 14:11:48 +01:00
<p class="govuk-body govuk-!-margin-bottom-2 live-broadcast live-broadcast--left">
Associate start time with live Start time is much more important than end time.
2020-10-14 14:16:16 +01:00
Live since {{ broadcast_message.starts_at|format_datetime_relative }}&ensp;
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
{%- if not hide_stop_link %}
Change 'broadcasting' to 'sending'
2021-07-05 17:42:37 +01:00
<a href="{{ url_for('.cancel_broadcast_message', service_id=current_service.id, broadcast_message_id=broadcast_message.id) }}" class="destructive-link destructive-link--no-visited-state">Stop sending</a>
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
{% endif %}
Move end time to bottom of page End time is less important than the status of the broadcast, or when it was started (eg when it was received by most people in the area).
2020-10-14 14:05:14 +01:00
</p>
Make alert page work for rejected broadcasts The code for this page was making assumptions about properties which aren’t present on rejected broadcasts. This commit accounts for those properties and presents the relevant elements on the page.
2021-04-08 13:34:29 +01:00
{% elif broadcast_message.status == 'rejected' %}
<p class="govuk-body govuk-!-margin-bottom-4">
Rejected
{{ broadcast_message.updated_at|format_datetime_human }}.
</p>
Move end time to bottom of page End time is less important than the status of the broadcast, or when it was started (eg when it was received by most people in the area).
2020-10-14 14:05:14 +01:00
{% else %}
<p class="govuk-body govuk-!-margin-bottom-4">
Replace 'broadcast' and 'prepared'
2021-07-05 16:41:17 +01:00
Sent
Move end time to bottom of page End time is less important than the status of the broadcast, or when it was started (eg when it was received by most people in the area).
2020-10-14 14:05:14 +01:00
{{ broadcast_message.starts_at|format_datetime_human }}.
</p>
{% endif %}
Add page for broadcast in pending state Since we’ll be linking to pending broadcasts from the dashboard, the page needs to be ready to display them. Pending broadcasts lack a few bits of information that live or previous broadcasts have (like the start date for example). So this commit hides the code that displays those bits of information.
2020-07-17 08:07:41 +01:00
{% endif %}
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
Swap order of message and areas This then matches the order in which the message is drafted, first the content, then the areas. It also matches the order we’re going to have on the new dashboard.
2020-10-14 13:59:20 +01:00
{{ broadcast_message.template|string }}
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
{% for area in broadcast_message.areas %}
{% if loop.first %}
Swap order of message and areas This then matches the order in which the message is drafted, first the content, then the areas. It also matches the order we’re going to have on the new dashboard.
2020-10-14 13:59:20 +01:00
<ul class="area-list">
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
{% endif %}
<li class="area-list-item area-list-item--unremoveable">
{{ area.name }}
</li>
{% if loop.last %}
</ul>
{% endif %}
{% endfor %}
Rename CSS classes for consistency This prefixes everything to do with areas/the map with `area-list`, so from looking at one element you know which `.scss` file will contain the relevant code.
2020-10-05 13:47:21 +01:00
<div class="area-list-map-details">
Adjust spacing and border on details map We hide the map inside a details element. Because the map has such a strong shape I don’t think it needs the grey border to contain it. This commit removes the border, and adjusts the spacing to group things by proximity alone. By removing the border and associated gutter we can give more space to the map, and make the page look less busy.
2020-10-02 14:51:57 +01:00
{{ govukDetails({
"summaryText": "Show map of areas",
"html": map(broadcast_message)
}) }}
</div>
Add map in details to broadcast view Avoided using `closest` as not supported by IE8-11 https://caniuse.com/#search=closest Used `parentElement` supported by IE9+ https://caniuse.com/#search=parentElement Used `className` as supported by IE9+ https://caniuse.com/#search=className Also rearranged the javascript for maps such that figuring out the polygon array is done first and then the time when we need to have the details component open before closing it again is kept to minimum
2020-09-03 10:55:01 +01:00
Move the ‘who did what’ stuff to the bottom The most important part of the broadcast is what content was sent where (and when). This commit reduces the priority of the ‘meta’ information, like who prepared and approved the broadcast. I also think that the ‘end’ time is a lot less important than the start time, since most people will receive the alert at or near to the start time.
2020-10-14 14:00:12 +01:00
{% if broadcast_message.status != 'pending-approval' %}
<p class="govuk-body govuk-!-margin-bottom-3">
Show broadcasts created by the API Broadcasts created by the API are different in that: - they aren’t created by any user, so don’t have a `created_by_id` - they are created instantly, not in steps, so don’t have an `updated_at` time This commit alters the views to account for when these pieces of information aren’t present.
2021-01-27 11:24:22 +00:00
{% if broadcast_message.created_by %}
Disambiguate sent and created At the moment we say that you either ‘add’ an alert or ‘send’ it. This is confusing because: - an alert isn’t received on people’s phones until it’s approved, so this is really when it is ‘sent’ conceptually - an alert can be rejected before anyone receives it, so the UI can say an alert that no-one ever received was sent This commit re-labels things so that the the first part of the process is ‘creating’ the alert. This makes all the permissions nice and distinct from each other. Adding templates and adding alerts feel conceptually quite different things (what are you adding the alert to?).
2021-07-22 14:27:22 +01:00
Created by {{ broadcast_message.created_by.name }}
Make alert page work for rejected broadcasts The code for this page was making assumptions about properties which aren’t present on rejected broadcasts. This commit accounts for those properties and presents the relevant elements on the page.
2021-04-08 13:34:29 +01:00
{%- else %}
Show broadcasts created by the API Broadcasts created by the API are different in that: - they aren’t created by any user, so don’t have a `created_by_id` - they are created instantly, not in steps, so don’t have an `updated_at` time This commit alters the views to account for when these pieces of information aren’t present.
2021-01-27 11:24:22 +00:00
Created from an API call
Make alert page work for rejected broadcasts The code for this page was making assumptions about properties which aren’t present on rejected broadcasts. This commit accounts for those properties and presents the relevant elements on the page.
2021-04-08 13:34:29 +01:00
{%- endif %}
{%- if broadcast_message.approved_by %}
and approved by {{ broadcast_message.approved_by.name }}
{%- endif %}
{{- '.' }}
Move the ‘who did what’ stuff to the bottom The most important part of the broadcast is what content was sent where (and when). This commit reduces the priority of the ‘meta’ information, like who prepared and approved the broadcast. I also think that the ‘end’ time is a lot less important than the start time, since most people will receive the alert at or near to the start time.
2020-10-14 14:00:12 +01:00
</p>
{% endif %}
Move end time to bottom of page End time is less important than the status of the broadcast, or when it was started (eg when it was received by most people in the area).
2020-10-14 14:05:14 +01:00
{% if broadcast_message.status == 'broadcasting' %}
<p class="govuk-body">
Broadcasting stops {{ broadcast_message.finishes_at|format_datetime_human }}.
</p>
{% elif broadcast_message.status == 'cancelled' %}
<p class="govuk-body">
Stopped by {{ broadcast_message.cancelled_by.name }}
{{ broadcast_message.cancelled_at|format_datetime_human }}.
</p>
{% elif broadcast_message.status == 'completed' %}
<p class="govuk-body">
Finished broadcasting {{ broadcast_message.finishes_at|format_datetime_human }}.
</p>
{% endif %}
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
{% endblock %}
Reference in New Issue Copy Permalink