darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-09-02 17:48:50 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
49ce146790d24bf5cc4e7adf87d24020e4e813a3
notifications-admin/app/templates/partials/jobs/notifications.html

68 lines
1.8 KiB
HTML
Raw Normal View History

Remove date table field type No longer used anywhere.
2016-09-09 15:41:32 +01:00
{% from "components/table.html" import list_table, field, right_aligned_field_heading, row_heading, notification_status_field %}
Add a cancel job button If you schedule a job you might change your mind or circumstances might change. So you need to be able to cancel it. This commit adds a button on the job page which hits the `…/cancel` API endpoint for a job.
2016-09-01 15:40:49 +01:00
{% from "components/page-footer.html" import page_footer %}
Make job page poll for updates This is a first go at having the job page update without refreshing. The approach I’ve taken is to do all the rendering of HTML on the server side, rather than use a Javascipt templating engine like mustache. This ensures that we don’t have to maintain two sets of templates. So the approach is to split the job page into partials. These partials can then: - be included in the job page to render the whole page - be rendered indivudually and then returned as a blob of HTML inside a JSON response Then I’ve added a Javascript module which looks for areas of the page that should be reloaded. For each area of the page it will poll a URL and re-render that section of the page when it gets new HTML. It implements some throttling so that API calls will never happen more frequently than 0.67 times/second.
2016-03-02 17:36:20 +00:00
Make sure partials always have a wrapping `<div>` The diffDOM Javascript sometimes throws an error if it can’t calculate a diff between the original content of the page and the updated HTML delivered via AJAX. The problem seems to be when there’s not one, consistent top-level element for it to base its calculations on. This commit: - makes sure that all AJAX-delivered partials have a wrapping `<div>` - that this `<div>` has a consistent class name to make it clear why it’s there
2016-09-01 11:06:52 +01:00
<div class="ajax-block-container">
{% if job.job_status == 'scheduled' %}
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
Make sure partials always have a wrapping `<div>` The diffDOM Javascript sometimes throws an error if it can’t calculate a diff between the original content of the page and the updated HTML delivered via AJAX. The problem seems to be when there’s not one, consistent top-level element for it to base its calculations on. This commit: - makes sure that all AJAX-delivered partials have a wrapping `<div>` - that this `<div>` has a consistent class name to make it clear why it’s there
2016-09-01 11:06:52 +01:00
<p>
Use days of week, not month for scheduled jobs Friday at 4pm is easier to understand than 14 October at 4pm, especially when the UI you’ve used to choose this time has talked about days of the week.
2016-10-12 09:20:32 +01:00
Sending will start {{ job.scheduled_for|format_datetime_relative }}
Make sure partials always have a wrapping `<div>` The diffDOM Javascript sometimes throws an error if it can’t calculate a diff between the original content of the page and the updated HTML delivered via AJAX. The problem seems to be when there’s not one, consistent top-level element for it to base its calculations on. This commit: - makes sure that all AJAX-delivered partials have a wrapping `<div>` - that this `<div>` has a consistent class name to make it clear why it’s there
2016-09-01 11:06:52 +01:00
</p>
Add a cancel job button If you schedule a job you might change your mind or circumstances might change. So you need to be able to cancel it. This commit adds a button on the job page which hits the `…/cancel` API endpoint for a job.
2016-09-01 15:40:49 +01:00
<div class="page-footer">
<form method="post">
{{ page_footer(
button_text="Cancel sending",
destructive=True
) }}
</form>
</div>
Show message on job page if job is scheduled If a job is scheduled then we can’t show the notifications yet, and the progress report will stay at 0%. In their place we should show what time a job will start. Later on (when the API is ready) this area of the page should also show a cancel button.
2016-08-25 16:49:31 +01:00
Make sure partials always have a wrapping `<div>` The diffDOM Javascript sometimes throws an error if it can’t calculate a diff between the original content of the page and the updated HTML delivered via AJAX. The problem seems to be when there’s not one, consistent top-level element for it to base its calculations on. This commit: - makes sure that all AJAX-delivered partials have a wrapping `<div>` - that this `<div>` has a consistent class name to make it clear why it’s there
2016-09-01 11:06:52 +01:00
{% else %}
Show message on job page if job is scheduled If a job is scheduled then we can’t show the notifications yet, and the progress report will stay at 0%. In their place we should show what time a job will start. Later on (when the API is ready) this area of the page should also show a cancel button.
2016-08-25 16:49:31 +01:00
Make sure partials always have a wrapping `<div>` The diffDOM Javascript sometimes throws an error if it can’t calculate a diff between the original content of the page and the updated HTML delivered via AJAX. The problem seems to be when there’s not one, consistent top-level element for it to base its calculations on. This commit: - makes sure that all AJAX-delivered partials have a wrapping `<div>` - that this `<div>` has a consistent class name to make it clear why it’s there
2016-09-01 11:06:52 +01:00
{% if notifications %}
<div class="dashboard-table">
{% endif %}
Make the job page look close to the activity page We can’t filter a job by notification status yet, but we can: - put the download link in the same place - make the table line up the same
2016-06-13 14:13:23 +01:00
Make sure partials always have a wrapping `<div>` The diffDOM Javascript sometimes throws an error if it can’t calculate a diff between the original content of the page and the updated HTML delivered via AJAX. The problem seems to be when there’s not one, consistent top-level element for it to base its calculations on. This commit: - makes sure that all AJAX-delivered partials have a wrapping `<div>` - that this `<div>` has a consistent class name to make it clear why it’s there
2016-09-01 11:06:52 +01:00
{% if not help %}
{% if percentage_complete < 100 %}
<p class="bottom-gutter-1-2 hint">
Report is {{ "{:.0f}%".format(percentage_complete) }} complete…
</p>
{% elif notifications %}
<p class="bottom-gutter">
<a href="{{ download_link }}" download="download" class="heading-small">Download this report</a>
&emsp;
<span id="time-left">{{ time_left }}</span>
</p>
{% endif %}
Link to failure reasons from job/activity pages If something has failed and you don’t know why, you should be able to find out why. Let’s try adding a link to the page explaining why, so it’s not just buried in the footer.
2016-07-11 13:53:55 +01:00
{% endif %}
Show message on job page if job is scheduled If a job is scheduled then we can’t show the notifications yet, and the progress report will stay at 0%. In their place we should show what time a job will start. Later on (when the API is ready) this area of the page should also show a cancel button.
2016-08-25 16:49:31 +01:00
Make sure partials always have a wrapping `<div>` The diffDOM Javascript sometimes throws an error if it can’t calculate a diff between the original content of the page and the updated HTML delivered via AJAX. The problem seems to be when there’s not one, consistent top-level element for it to base its calculations on. This commit: - makes sure that all AJAX-delivered partials have a wrapping `<div>` - that this `<div>` has a consistent class name to make it clear why it’s there
2016-09-01 11:06:52 +01:00
{% call(item, row_number) list_table(
notifications,
caption=uploaded_file_name,
caption_visible=False,
empty_message="No messages to show",
field_headings=[
'Recipient',
'Status'
],
field_headings_visible=False
Show message on job page if job is scheduled If a job is scheduled then we can’t show the notifications yet, and the progress report will stay at 0%. In their place we should show what time a job will start. Later on (when the API is ready) this area of the page should also show a cancel button.
2016-08-25 16:49:31 +01:00
) %}
Make sure partials always have a wrapping `<div>` The diffDOM Javascript sometimes throws an error if it can’t calculate a diff between the original content of the page and the updated HTML delivered via AJAX. The problem seems to be when there’s not one, consistent top-level element for it to base its calculations on. This commit: - makes sure that all AJAX-delivered partials have a wrapping `<div>` - that this `<div>` has a consistent class name to make it clear why it’s there
2016-09-01 11:06:52 +01:00
{% call row_heading() %}
Fix overlapping text on tables of notifications This commit changes the tables of notifications from 3 columns to two columns. This is so the text has more room, so it doesn’t start overlapping. It also makes sure that if the recipient gets really long that it will be cut off with an ellipsis, rather than overlapping… I hypothesize that if a notification fails you probably don’t care when it failed, just that it failed.
2016-09-09 12:25:39 +01:00
<p>{{ item.to }}</p>
Make sure partials always have a wrapping `<div>` The diffDOM Javascript sometimes throws an error if it can’t calculate a diff between the original content of the page and the updated HTML delivered via AJAX. The problem seems to be when there’s not one, consistent top-level element for it to base its calculations on. This commit: - makes sure that all AJAX-delivered partials have a wrapping `<div>` - that this `<div>` has a consistent class name to make it clear why it’s there
2016-09-01 11:06:52 +01:00
{% endcall %}
Refactor notification status into its own field type
2016-09-09 15:40:27 +01:00
{{ notification_status_field(item) }}
Show message on job page if job is scheduled If a job is scheduled then we can’t show the notifications yet, and the progress report will stay at 0%. In their place we should show what time a job will start. Later on (when the API is ready) this area of the page should also show a cancel button.
2016-08-25 16:49:31 +01:00
{% endcall %}
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
Make sure partials always have a wrapping `<div>` The diffDOM Javascript sometimes throws an error if it can’t calculate a diff between the original content of the page and the updated HTML delivered via AJAX. The problem seems to be when there’s not one, consistent top-level element for it to base its calculations on. This commit: - makes sure that all AJAX-delivered partials have a wrapping `<div>` - that this `<div>` has a consistent class name to make it clear why it’s there
2016-09-01 11:06:52 +01:00
{% if more_than_one_page %}
<p class="table-show-more-link">
Only showing the first 50 rows
</p>
{% endif %}
{% if notifications %}
</div>
Show message on job page if job is scheduled If a job is scheduled then we can’t show the notifications yet, and the progress report will stay at 0%. In their place we should show what time a job will start. Later on (when the API is ready) this area of the page should also show a cancel button.
2016-08-25 16:49:31 +01:00
{% endif %}
Add a message if there are more than 50 rows Similar to how we do it on the check page, we should indicate if there are more results than we can show. No-one’s really complained about the absence of this, but it can’t hurt.
2016-08-02 10:34:27 +01:00
{% endif %}
Make sure partials always have a wrapping `<div>` The diffDOM Javascript sometimes throws an error if it can’t calculate a diff between the original content of the page and the updated HTML delivered via AJAX. The problem seems to be when there’s not one, consistent top-level element for it to base its calculations on. This commit: - makes sure that all AJAX-delivered partials have a wrapping `<div>` - that this `<div>` has a consistent class name to make it clear why it’s there
2016-09-01 11:06:52 +01:00
</div>
Reference in New Issue Copy Permalink