darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-09-09 05:23:12 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
ef8cab7fa418e2c33db28d9f0986e944f01034c0
notifications-admin/app/templates/views/jobs/job.html

37 lines
1.4 KiB
HTML
Raw Normal View History

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
{% extends "withnav_template.html" %}
{% from "components/banner.html" import banner %}
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 %}
Add a back to template link on job page When you’ve sent message(s) using a template, often the next thing you want to do is go and send the same template again, or edit it. Currently there’s no way of getting to a template from a job except for going back to the list of templates and re-finding it. This commit adds a link at the bottom of the job page that gives you a shortcut back to the individual template, where you can find actions like edit/send/etc.
2017-03-22 10:55:15 +00:00
{% from "components/page-footer.html" import page_footer %}
Fix navigation around uploads and jobs The uploads and jobs page should start showing in the _Uploads_ menu on the left hand side. If you’ve navigated to a job from the uploads page (ie you haven’t got to that page because you’ve just sent the job) then you should see a link back to the uploads page.
2020-03-03 14:27:13 +00:00
{% from "components/page-header.html" import page_header %}
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
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 %}
Make a job model for individual jobs This follows the pattern of what we’ve done with services, users and events. It gives us a better interface to the data we get back from the API than dealing with the raw JSON directly. Now is a good time to do this because we’re going to be making a bunch of changes to the jobs pages, and those changes will be easier to code and understand with a sesnsible model behind them.
2020-01-08 12:23:09 +00:00
{{ job.original_file_name }}
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
{% endblock %}
{% block maincolumn_content %}
Fix navigation around uploads and jobs The uploads and jobs page should start showing in the _Uploads_ menu on the left hand side. If you’ve navigated to a job from the uploads page (ie you haven’t got to that page because you’ve just sent the job) then you should see a link back to the uploads page.
2020-03-03 14:27:13 +00:00
{{ page_header(
job.original_file_name,
back_link=None if just_sent else url_for('main.uploads', service_id=current_service.id)
) }}
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
Fix navigation around uploads and jobs The uploads and jobs page should start showing in the _Uploads_ menu on the left hand side. If you’ve navigated to a job from the uploads page (ie you haven’t got to that page because you’ve just sent the job) then you should see a link back to the uploads page.
2020-03-03 14:27:13 +00:00
{% if just_sent and job.template_type == 'letter' %}
Update banner message for CSV letters This was always showing the text 'Your letter has been sent...' This has now been updated to start 'Your letters have been sent...' if a job has more than one notification in it.
2018-11-29 11:37:38 +00:00
{{ banner(just_sent_message, type='default', with_tick=True) }}
Show confirmation after pressing big green button There’s no immediate feedback with letter jobs, unlike email or text messages jobs where you see the numbers starting to tick over straight away. We need to reassure the user that the thing they asked us to do (send letters) is underway. ‘Printing’ feels like the natural first state of the letter-making process. So this commit adds a banner to tell the user that printing is the thing that’s happening.
2017-07-13 11:28:37 +01:00
{% else %}
Refactor ‘finished’ to the model layer By moving it from the view we reduce the complexity of the methods in the view layer, so it’s easier to see what they do. This also renames the variable `finished` to the property `processing_finished` to disambiguate from the `job_status` field in the JSON, which can also have a value of `finished`.
2020-01-08 16:23:43 +00:00
{{ ajax_block(partials, updates_url, 'status', finished=job.processing_finished) }}
Show confirmation after pressing big green button There’s no immediate feedback with letter jobs, unlike email or text messages jobs where you see the numbers starting to tick over straight away. We need to reassure the user that the thing they asked us to do (send letters) is underway. ‘Printing’ feels like the natural first state of the letter-making process. So this commit adds a banner to tell the user that printing is the thing that’s happening.
2017-07-13 11:28:37 +01:00
{% endif %}
Refactor ‘finished’ to the model layer By moving it from the view we reduce the complexity of the methods in the view layer, so it’s easier to see what they do. This also renames the variable `finished` to the property `processing_finished` to disambiguate from the `job_status` field in the JSON, which can also have a value of `finished`.
2020-01-08 16:23:43 +00:00
{{ ajax_block(partials, updates_url, 'counts', finished=job.processing_finished) }}
{{ ajax_block(partials, updates_url, 'notifications', finished=job.processing_finished) }}
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 a job model for individual jobs This follows the pattern of what we’ve done with services, users and events. It gives us a better interface to the data we get back from the API than dealing with the raw JSON directly. Now is a good time to do this because we’re going to be making a bunch of changes to the jobs pages, and those changes will be easier to code and understand with a sesnsible model behind them.
2020-01-08 12:23:09 +00:00
{% if job.letter_job_can_be_cancelled %}
User can cancel a letter job - happy path
2019-06-18 15:52:29 +01:00
<div class="js-stick-at-bottom-when-scrolling">
<div class="page-footer">
<span class="page-footer-delete-link page-footer-delete-link-without-button">
Convert warning links to govuk-link--destructive Converts links in the following: - the page-footer component - the table component - the browse-list component - the notification status, when reporting failures - validation messaging in the whitelist page
2020-02-10 12:13:24 +00:00
<a class="govuk-link govuk-link--destructive" href="{{ url_for('main.cancel_letter_job', service_id=current_service.id, job_id=job.id) }}">Cancel sending these letters</a>
User can cancel a letter job - happy path
2019-06-18 15:52:29 +01:00
</span>
{% else %}
<div>&nbsp;</div>
{% endif %}
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
{% endblock %}
Reference in New Issue Copy Permalink