darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-08-18 05:29:38 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
bfc55b45ca21ece7bf1b2c98debdbde2283810ea
notifications-admin/app/templates/views/broadcast/view-message.html

184 lines
7.1 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 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/button/macro.njk" import govukButton %}
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' %}
Admins won't see buttons for broadcast actions they can't do These actions are creating, accepting and rejecting broadcasts.
2021-04-14 18:13:18 +01:00
{% if broadcast_message.created_by and broadcast_message.created_by == current_user and current_user.has_permissions('send_messages', 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
Admins won't see buttons for broadcast actions they can't do These actions are creating, accepting and rejecting broadcasts.
2021-04-14 18:13:18 +01:00
{% elif current_user.has_permissions('send_messages', 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 %}
{% block maincolumn_content %}
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 }) }}
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' %}
Admins won't see buttons for broadcast actions they can't do These actions are creating, accepting and rejecting broadcasts.
2021-04-14 18:13:18 +01:00
{% if broadcast_message.created_by and broadcast_message.created_by == current_user and current_user.has_permissions('send_messages', 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),
delete_link_text='Withdraw this alert'
) }}
{% else %}
<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),
delete_link_text='Cancel this alert'
) }}
{% endcall %}
</details>
{% 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>
Admins won't see buttons for broadcast actions they can't do These actions are creating, accepting and rejecting broadcasts.
2021-04-14 18:13:18 +01:00
{% elif current_user.has_permissions('send_messages', 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>
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 %}
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 %}
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
<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 broadcasting</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">
Broadcast
{{ 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 %}
Prepared 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