darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-08-11 09:28:27 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
0a56941bb99daeee57e5531f0e33d2a4e486fa3c
notifications-admin/app/templates/views/dashboard/dashboard.html

114 lines
4.7 KiB
HTML
Raw Normal View History

Put some statistics on the dashboard This commit adds two new sections to the dashboard 1. A banner telling you about trial mode, including a count of how many messages you have left today, which is a restriction of trial mode 2. Panels with counts of how many emails and text messages have been sent in a day, plus the failure rates for each It does **not**: - link through to any further information about what trial mode is (coming later) - link through to pages for the failure rates (coming later) - change the ‘recent jobs’ section to ‘recent notifications’
2016-03-17 11:45:48 +00:00
{% extends "withnav_template.html" %}
moved table to dashboard
2024-01-03 00:26:49 -08:00
{% from "components/table.html" import list_table, field, text_field, link_field, right_aligned_field_heading, hidden_field_heading, row_heading, notification_status_field, notification_carrier_field, notification_carrier_message_field %}
Make a macro for the AJAX update module This is less repetitive than typing out the HTML with all its attributes every time. It also lets us wrap up the idea of ‘finished’ as a parameter, so the AJAX code will only be initiated when it’s needed, eg if a job is still processing.
2016-06-28 09:21:46 +01:00
{% from "components/ajax-block.html" import ajax_block %}
Refactor dashboard templates Previously the structure was ``` dashboard.html |_ today.html |_ some random html |_ a few things split into partials ``` This commit simplifies the structure to just be: ``` dashboard.html |_ partial |_ partial |_ … ```
2016-06-28 08:59:08 +01:00
Include service name in page `<title>` In pages specific to a service (e.g. dashboard and sub pages) the title needs to distinguish which service it applies to. This is mainly to give context to screen reader users who could be managing multiple services. Implementing this uses template inheritance: `page_title` includes `per_page_title` includes `service_page_title` ‘GOV.UK Notify’ is inserted into every page title. Pages that set `service_page_title` get the service name inserted too.
2017-02-13 10:45:15 +00:00
{% block service_page_title %}
Dashboard
Put some statistics on the dashboard This commit adds two new sections to the dashboard 1. A banner telling you about trial mode, including a count of how many messages you have left today, which is a restriction of trial mode 2. Panels with counts of how many emails and text messages have been sent in a day, plus the failure rates for each It does **not**: - link through to any further information about what trial mode is (coming later) - link through to pages for the failure rates (coming later) - change the ‘recent jobs’ section to ‘recent notifications’
2016-03-17 11:45:48 +00:00
{% endblock %}
{% block maincolumn_content %}
Template statistics now surfaced on dashboard. Job list removed. Template statistics retrieved at same time as notification stats.
2016-04-05 11:40:13 +01:00
Update dashboard and template flow (#514) * Updated header and footer * Moved files around and updated gulpfile to correct the build process when it goes to production * Updated fonts * Adjusted grid templating * Adding images to assets * Updated account pages, dashboard, and pages in message sending flow * Updated the styling for the landing pages in the account section once logged in
2023-06-08 13:12:00 -04:00
<div class="dashboard margin-bottom-8">
Add usage to the dashboard Takes the number of emails and SMS fragments sent from: https://github.com/alphagov/notifications-api/pull/273 Using these numbers it’s possible to show: - how much of your allowance is left - or how much you have spent For now the allowance and rates are hard coded. Only for users that have manage service.
2016-04-20 15:37:17 +01:00
Update dashboard and template flow (#514) * Updated header and footer * Moved files around and updated gulpfile to correct the build process when it goes to production * Updated fonts * Adjusted grid templating * Adding images to assets * Updated account pages, dashboard, and pages in message sending flow * Updated the styling for the landing pages in the account section once logged in
2023-06-08 13:12:00 -04:00
<h1 class="usa-sr-only">Dashboard</h1>
Add Service.get_templates method with filters by type and folder With the addition of template folders we need to filter templates based on a combination of type and parent folder ID. This replaces the existing `templates_by_type` method with `get_templates`, which supports both type and parent folder filters, avoiding a need to create specific methods for each use case. We still need the templates property to exist in some way in order to cache it, but it needs to be clear that it's different from `.get_templates`. One option was to make it "private" (i.e. `_templates`), and always use `.get_templates` in the rest of the code, but this requires adding "include all folders" to `.get_templates`, which doesn't have an obvious interface since `parent_folder_id=None` already means "top-level only". This will probably come up again when we need to look into adding templates from nested folders into the page for live search, but for now renaming `Service.templates` to `.all_templates` makes it clear what the property contains.
2018-11-05 15:26:59 +00:00
{% if current_user.has_permissions('manage_templates') and not current_service.all_templates %}
Remove warning banner from dashboard (and app) We have teams who are using the dashboard every day, and being confronted with this alarming yellow banner. There’s no action they need to do since they’re only looking at the messages sent. So this commit removes that banner from the dashboard. It also removes the CSS and HTML for it from the app entirely because this is the last remaining place we were using this style of banner.
2018-03-12 15:49:52 +00:00
{% include 'views/dashboard/write-first-messages.html' %}
Show a tour when users first create a service This commit adds a 3 screen tour, similar to those used on GOV.UK Verify and Passports. We guerilla tested this on Friday, and it really helped users to build a mental model of how Notify works, so that when they’re playing around with it they have a greater sense of what they’re aiming to do. This makes concepts like templates and placeholders click more quickly. https://www.pivotaltracker.com/story/show/116710119
2016-04-01 10:54:55 +01:00
{% endif %}
Put some statistics on the dashboard This commit adds two new sections to the dashboard 1. A banner telling you about trial mode, including a count of how many messages you have left today, which is a restriction of trial mode 2. Panels with counts of how many emails and text messages have been sent in a day, plus the failure rates for each It does **not**: - link through to any further information about what trial mode is (coming later) - link through to pages for the failure rates (coming later) - change the ‘recent jobs’ section to ‘recent notifications’
2016-03-17 11:45:48 +00:00
Delay AJAX calls if the server is slow to respond By default our AJAX calls were 2 seconds. Then they were 5 seconds because someone reckoned 2 seconds was putting too much load on the system. Then we made them 10 seconds while we were having an incident. Then we made them 20 seconds for the heaviest pages, but back to 5 seconds or 2 seconds for the rest of the pages. This is not a good situation because: - it slows all services down equally, no matter how much traffic they have, or which features they have switched on - it slows everything down by the same amount, no matter how much load the platform is under - the values are set based on our worst performance, until we manually remember to switch them back - we spend time during incidents deploying changes to slow down the dashboard refresh time because it’s a nothing-to-lose change that might relieve some symptoms, when we could be spending time digging into the underlying cause This pull request makes the Javascript smarter about how long it waits until it makes another AJAX call. It bases the delay on how long the server takes to respond (as a proxy for how much load the server is under). It’s based on the square root of the response time, so is more sensitive to slow downs early on, and less sensitive to slow downs later on. This helps us give a more pronounced difference in delay between an AJAX call that is fast (for example the page for a single notification) and one that is slow (for example a dashboard for a service with lots of traffic). *Some examples of what this would mean for various pages* Page | Response time | Wait until next AJAX call ---|---|--- Check a reply to address | 130ms | 1,850ms Brand new service dashboard | 229ms | 2,783ms HM Passport Office dashboard | 634ms | 5,294ms NHS Coronavirus Service dashboard | 779ms | 5,977ms _Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
{{ ajax_block(partials, updates_url, 'upcoming') }}
Show upcoming jobs on the dashboard On the dashboard: - adds a new ‘in the next 24 hours’ section to the dashboard which lists upcoming jobs - tweaks some spacing on the dashboard so that it doesn’t look like too much of a mess - don’t show scheduled jobs in the table of normal jobs On the jobs page: - don’t show scheduled jobs
2016-08-09 10:39:57 +01:00
Few style updates per PR feedback
2024-03-21 11:00:44 -04:00
<h2 class="font-body-2xl line-height-sans-2 margin-0">
Changing the layout of the page to a table view
2023-10-31 14:22:00 -04:00
Messages sent
Make template usage on dashboard easier to scan The dashboard looked a bit table-y. This commit makes four main changes: - show a bar chart (drawn in CSS) for template usage (only shown if you’ve used more than one template recently) - only break down template usage by template name, not template type (because that’s happening with the big numbers) - change the style of the ‘show more’ links under each section so that they are all consistent, and a little less busy (one less keyline) - remove the ‘recent templates‘ title so that the first two sections of the page group under ‘in the last 7 days’
2016-05-11 15:05:40 +01:00
</h2>
Refactor dashboard templates Previously the structure was ``` dashboard.html |_ today.html |_ some random html |_ a few things split into partials ``` This commit simplifies the structure to just be: ``` dashboard.html |_ partial |_ partial |_ … ```
2016-06-28 08:59:08 +01:00
added sampleChartDashboard.js
2024-06-06 10:05:36 -07:00
<!-- <button id="sevenDaysButton">7 Days</button>
<canvas id="myChart" data-service-id="{{ service_id }}"></canvas> -->
Delay AJAX calls if the server is slow to respond By default our AJAX calls were 2 seconds. Then they were 5 seconds because someone reckoned 2 seconds was putting too much load on the system. Then we made them 10 seconds while we were having an incident. Then we made them 20 seconds for the heaviest pages, but back to 5 seconds or 2 seconds for the rest of the pages. This is not a good situation because: - it slows all services down equally, no matter how much traffic they have, or which features they have switched on - it slows everything down by the same amount, no matter how much load the platform is under - the values are set based on our worst performance, until we manually remember to switch them back - we spend time during incidents deploying changes to slow down the dashboard refresh time because it’s a nothing-to-lose change that might relieve some symptoms, when we could be spending time digging into the underlying cause This pull request makes the Javascript smarter about how long it waits until it makes another AJAX call. It bases the delay on how long the server takes to respond (as a proxy for how much load the server is under). It’s based on the square root of the response time, so is more sensitive to slow downs early on, and less sensitive to slow downs later on. This helps us give a more pronounced difference in delay between an AJAX call that is fast (for example the page for a single notification) and one that is slow (for example a dashboard for a service with lots of traffic). *Some examples of what this would mean for various pages* Page | Response time | Wait until next AJAX call ---|---|--- Check a reply to address | 130ms | 1,850ms Brand new service dashboard | 229ms | 2,783ms HM Passport Office dashboard | 634ms | 5,294ms NHS Coronavirus Service dashboard | 779ms | 5,977ms _Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
{{ ajax_block(partials, updates_url, 'inbox') }}
Show inbound messages on the dashboard This commit adds two things: a section on the dashboard to show how many inbound messages the service has received in the last 7 days, and how recently an inbound message has been received --- Doesn’t show the contents of any messages, just like how the rest of the dashboard is an aggregation, never individual messages. a page to show all the inbound messages the service has received in the last 7 days --- This shows the first line of the message. Eventually this will link through to a ‘conversation’ page, where a service can see all the messages it’s received from a given phone number.
2017-05-22 17:02:03 +01:00
Delay AJAX calls if the server is slow to respond By default our AJAX calls were 2 seconds. Then they were 5 seconds because someone reckoned 2 seconds was putting too much load on the system. Then we made them 10 seconds while we were having an incident. Then we made them 20 seconds for the heaviest pages, but back to 5 seconds or 2 seconds for the rest of the pages. This is not a good situation because: - it slows all services down equally, no matter how much traffic they have, or which features they have switched on - it slows everything down by the same amount, no matter how much load the platform is under - the values are set based on our worst performance, until we manually remember to switch them back - we spend time during incidents deploying changes to slow down the dashboard refresh time because it’s a nothing-to-lose change that might relieve some symptoms, when we could be spending time digging into the underlying cause This pull request makes the Javascript smarter about how long it waits until it makes another AJAX call. It bases the delay on how long the server takes to respond (as a proxy for how much load the server is under). It’s based on the square root of the response time, so is more sensitive to slow downs early on, and less sensitive to slow downs later on. This helps us give a more pronounced difference in delay between an AJAX call that is fast (for example the page for a single notification) and one that is slow (for example a dashboard for a service with lots of traffic). *Some examples of what this would mean for various pages* Page | Response time | Wait until next AJAX call ---|---|--- Check a reply to address | 130ms | 1,850ms Brand new service dashboard | 229ms | 2,783ms HM Passport Office dashboard | 634ms | 5,294ms NHS Coronavirus Service dashboard | 779ms | 5,977ms _Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
{{ ajax_block(partials, updates_url, 'totals') }}
Refactor dashboard templates Previously the structure was ``` dashboard.html |_ today.html |_ some random html |_ a few things split into partials ``` This commit simplifies the structure to just be: ``` dashboard.html |_ partial |_ partial |_ … ```
2016-06-28 08:59:08 +01:00
Delay AJAX calls if the server is slow to respond By default our AJAX calls were 2 seconds. Then they were 5 seconds because someone reckoned 2 seconds was putting too much load on the system. Then we made them 10 seconds while we were having an incident. Then we made them 20 seconds for the heaviest pages, but back to 5 seconds or 2 seconds for the rest of the pages. This is not a good situation because: - it slows all services down equally, no matter how much traffic they have, or which features they have switched on - it slows everything down by the same amount, no matter how much load the platform is under - the values are set based on our worst performance, until we manually remember to switch them back - we spend time during incidents deploying changes to slow down the dashboard refresh time because it’s a nothing-to-lose change that might relieve some symptoms, when we could be spending time digging into the underlying cause This pull request makes the Javascript smarter about how long it waits until it makes another AJAX call. It bases the delay on how long the server takes to respond (as a proxy for how much load the server is under). It’s based on the square root of the response time, so is more sensitive to slow downs early on, and less sensitive to slow downs later on. This helps us give a more pronounced difference in delay between an AJAX call that is fast (for example the page for a single notification) and one that is slow (for example a dashboard for a service with lots of traffic). *Some examples of what this would mean for various pages* Page | Response time | Wait until next AJAX call ---|---|--- Check a reply to address | 130ms | 1,850ms Brand new service dashboard | 229ms | 2,783ms HM Passport Office dashboard | 634ms | 5,294ms NHS Coronavirus Service dashboard | 779ms | 5,977ms _Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
{{ ajax_block(partials, updates_url, 'template-statistics') }}
updated table titles and fields
2024-01-19 11:44:25 -08:00
<h2 class="margin-top-4 margin-bottom-1">Recent Batches</h2>
When resizing the viewport for the header, I noticed other responsive issues and addressed them here
2024-03-05 09:51:25 -05:00
<div class="table-wrapper">
updated pytest
2024-02-12 15:29:26 -08:00
<table class="usa-table usa-table--borderless job-table">
updated download links and table html
2024-01-25 15:32:44 -08:00
<thead class="table-field-headings">
<tr>
updated css table widths
2024-02-12 16:33:41 -08:00
<th scope="col" class="table-field-heading-first">
updated download links and table html
2024-01-25 15:32:44 -08:00
<span>File name</span>
</th>
updated css table widths
2024-02-12 16:33:41 -08:00
<th scope="col" class="table-field-heading">
updated download links and table html
2024-01-25 15:32:44 -08:00
<span>Template</span>
</th>
updated css table widths
2024-02-12 16:33:41 -08:00
<th scope="col" class="table-field-heading">
updated download links and table html
2024-01-25 15:32:44 -08:00
<span>Time sent</span>
</th>
updated css table widths
2024-02-12 16:33:41 -08:00
<th scope="col" class="table-field-heading">
updated download links and table html
2024-01-25 15:32:44 -08:00
<span>Sender</span>
</th>
updated css table widths
2024-02-12 16:33:41 -08:00
<th scope="col" class="table-field-heading">
updated download links and table html
2024-01-25 15:32:44 -08:00
<span># of Recipients</span>
</th>
updated css table widths
2024-02-12 16:33:41 -08:00
<th scope="col" class="table-field-heading">
updated download links and table html
2024-01-25 15:32:44 -08:00
<span>Report</span>
</th>
</tr>
</thead>
<tbody>
updated pytest
2024-02-12 15:29:26 -08:00
{% if job_and_notifications %}
limit 5 in table
2024-02-12 16:34:54 -08:00
{% for job in job_and_notifications[:5] %}
updated pytest
2024-02-12 15:29:26 -08:00
{% if job.job_id and job.notifications %}
{% set notification = job.notifications[0] %}
fixed duplicates to notification by adding aggregate
2024-02-09 17:09:48 -08:00
<tr class="table-row" id="{{ job.job_id }}">
updated css table widths
2024-02-12 16:33:41 -08:00
<td class="table-field file-name">
Updated filename string into db and UI display
2024-05-02 12:53:27 -06:00
{{ notification.job.original_file_name[:12] if notification.job.original_file_name else 'Manually entered number'}}
fixed duplicates to notification by adding aggregate
2024-02-09 17:09:48 -08:00
<br>
<a class="usa-link file-list-filename" href="{{ job.view_job_link }}">View Batch</a>
updated pytest
2024-02-12 15:29:26 -08:00
</td>
updated css table widths
2024-02-12 16:33:41 -08:00
<td class="table-field template">
fixed duplicates to notification by adding aggregate
2024-02-09 17:09:48 -08:00
{{ notification.template.name }}
updated pytest
2024-02-12 15:29:26 -08:00
</td>
updated css table widths
2024-02-12 16:33:41 -08:00
<td class="table-field time-sent">
updated datetimes based on style guide
2024-03-18 15:10:26 -07:00
{{ job.created_at | format_datetime_table }}
updated pytest
2024-02-12 15:29:26 -08:00
</td>
updated css table widths
2024-02-12 16:33:41 -08:00
<td class="table-field sender">
fixed duplicates to notification by adding aggregate
2024-02-09 17:09:48 -08:00
{{ notification.created_by.name }}
updated pytest
2024-02-12 15:29:26 -08:00
</td>
updated css table widths
2024-02-12 16:33:41 -08:00
<td class="table-field count-of-recipients">
fixed duplicates to notification by adding aggregate
2024-02-09 17:09:48 -08:00
{{ job.notification_count}}
updated pytest
2024-02-12 15:29:26 -08:00
</td>
updated css table widths
2024-02-12 16:33:41 -08:00
<td class="table-field report">
fixed duplicates to notification by adding aggregate
2024-02-09 17:09:48 -08:00
{% if notification and job.time_left != "Data no longer available" %}
<a class="usa-link file-list-filename" href="{{ job.download_link }}">Download</a>
<span class="usa-hint">{{ job.time_left }}</span>
{% elif job %}
<span>{{ job.time_left }}</span>
{% endif %}
updated pytest
2024-02-12 15:29:26 -08:00
</td>
fixed duplicates to notification by adding aggregate
2024-02-09 17:09:48 -08:00
</tr>
updated pytest
2024-02-12 15:29:26 -08:00
{% endif %}
{% endfor %}
{% else %}
<tr class="table-row">
<td class="table-empty-message" colspan="10">No batched job messages found &thinsp;(messages are kept for {{ service_data_retention_days }} days).</td>
</tr>
{% endif %}
updated download links and table html
2024-01-25 15:32:44 -08:00
</tbody>
</table>
removed notification conditional
2024-01-12 13:32:10 -08:00
</div>
1213 - Removed the Usage page and updated the Dashboard Landing page
2024-03-28 15:58:02 -04:00
<h2 class="margin-top-4 margin-bottom-1">Message count</h2>
Put usage summary back on the dashboard This reverts 1b1839ad301725c179a2f5b5d1fe43b66ea41e50, which removed the usage from the dashboard because it was causing performance problems: > **The yearly usage section on the dashboard page takes too log as a > result services with large yearly stats are timing out.** > > As a short term fix we have taken the yearly stats off the dashboard. > > There is a plan to create permanent statistic tables to warehouse the > data. The long term fix (the fact tables) is now in place, so it should be OK to bring this back. This is part of a wider piece of work to refresh the dashboard page now that jobs are moving to their own page.
2019-10-25 13:27:46 +01:00
{% if current_user.has_permissions('manage_service') %}
927 - Updates to math in Dashboard area
2023-11-16 12:02:59 -05:00
<h3 class='margin-bottom-0' id="current-year"></h3>
Delay AJAX calls if the server is slow to respond By default our AJAX calls were 2 seconds. Then they were 5 seconds because someone reckoned 2 seconds was putting too much load on the system. Then we made them 10 seconds while we were having an incident. Then we made them 20 seconds for the heaviest pages, but back to 5 seconds or 2 seconds for the rest of the pages. This is not a good situation because: - it slows all services down equally, no matter how much traffic they have, or which features they have switched on - it slows everything down by the same amount, no matter how much load the platform is under - the values are set based on our worst performance, until we manually remember to switch them back - we spend time during incidents deploying changes to slow down the dashboard refresh time because it’s a nothing-to-lose change that might relieve some symptoms, when we could be spending time digging into the underlying cause This pull request makes the Javascript smarter about how long it waits until it makes another AJAX call. It bases the delay on how long the server takes to respond (as a proxy for how much load the server is under). It’s based on the square root of the response time, so is more sensitive to slow downs early on, and less sensitive to slow downs later on. This helps us give a more pronounced difference in delay between an AJAX call that is fast (for example the page for a single notification) and one that is slow (for example a dashboard for a service with lots of traffic). *Some examples of what this would mean for various pages* Page | Response time | Wait until next AJAX call ---|---|--- Check a reply to address | 130ms | 1,850ms Brand new service dashboard | 229ms | 2,783ms HM Passport Office dashboard | 634ms | 5,294ms NHS Coronavirus Service dashboard | 779ms | 5,977ms _Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
{{ ajax_block(partials, updates_url, 'usage') }}
1213 - Removed the Usage page and updated the Dashboard Landing page
2024-03-28 15:58:02 -04:00
<p class="margin-top-0">During the pilot period, each service has an allowance of 250,000 message parts. Once this allowance is met, the
application will stop delivering messages. There's no monthly charge, no setup fee, and no procurement cost.</p>
<p class="align-with-heading-copy">
What counts as 1 text message part?<br />
See <a class="usa-link" href="{{ url_for('.pricing') }}">pricing</a>.
</p>
Put usage summary back on the dashboard This reverts 1b1839ad301725c179a2f5b5d1fe43b66ea41e50, which removed the usage from the dashboard because it was causing performance problems: > **The yearly usage section on the dashboard page takes too log as a > result services with large yearly stats are timing out.** > > As a short term fix we have taken the yearly stats off the dashboard. > > There is a plan to create permanent statistic tables to warehouse the > data. The long term fix (the fact tables) is now in place, so it should be OK to bring this back. This is part of a wider piece of work to refresh the dashboard page now that jobs are moving to their own page.
2019-10-25 13:27:46 +01:00
{% endif %}
Add usage to the dashboard Takes the number of emails and SMS fragments sent from: https://github.com/alphagov/notifications-api/pull/273 Using these numbers it’s possible to show: - how much of your allowance is left - or how much you have spent For now the allowance and rates are hard coded. Only for users that have manage service.
2016-04-20 15:37:17 +01:00
</div>
Put some statistics on the dashboard This commit adds two new sections to the dashboard 1. A banner telling you about trial mode, including a count of how many messages you have left today, which is a restriction of trial mode 2. Panels with counts of how many emails and text messages have been sent in a day, plus the failure rates for each It does **not**: - link through to any further information about what trial mode is (coming later) - link through to pages for the failure rates (coming later) - change the ‘recent jobs’ section to ‘recent notifications’
2016-03-17 11:45:48 +00:00
{% endblock %}
Reference in New Issue Copy Permalink