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
e6f49825e5fdfd798ca2f2622f12342dfd15dbf8
notifications-admin/app/main/views/jobs.py

454 lines
15 KiB
Python
Raw Normal View History

Added encoding to file
2016-01-06 11:03:29 +00:00
# -*- coding: utf-8 -*-
Changed page flow to first save file and then redirect to check. On check numbers in file are validated. Posting to check then uploads file to s3
2016-01-13 17:32:40 +00:00
Link back to uploaded letters page If you’ve come to look at a notification via the uploaded letters page then the ‘< back’ link should take you back there, not to the usual activity page.
2020-05-11 14:20:53 +01:00
from functools import partial
Changed page flow to first save file and then redirect to check. On check numbers in file are validated. Posting to check then uploads file to s3
2016-01-13 17:32:40 +00:00
from flask import (
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
Response,
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
abort,
User can cancel a letter job - happy path
2019-06-18 15:52:29 +01:00
flash,
Notification history page added and pagination, tests all working.
2016-03-16 16:57:10 +00:00
jsonify,
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
redirect,
render_template,
Allow filter links to be used in combination Means you can see, for example emails that have failed. Means adding: - logic to generate links which can have a type parameter, a status parameter, or both - a ‘pill’ UI component for seeing which filters you currently have applied - some logic to change the page title based on which filters you have applied
2016-04-13 12:50:28 +01:00
request,
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
stream_with_context,
Change activity to view to request 7 days data. Cleaned up filters a bit so that if you want both templates email and sms is passed. Added mock assertion to test.
2016-04-28 15:50:05 +01:00
url_for,
Changed page flow to first save file and then redirect to check. On check numbers in file are validated. Posting to check then uploads file to s3
2016-01-13 17:32:40 +00:00
)
Have permissions decorators check user signed in Rather than force us to write the decorators in a specific order let’s just have one decorator call the other. This should make fewer lines of code, and fewer annoying test failures. It also means that the same way of raising a `401` (through the `current_app` method) is used everywhere.
2019-07-01 15:22:08 +01:00
from flask_login import current_user
User can cancel a letter job - happy path
2019-06-18 15:52:29 +01:00
from notifications_python_client.errors import HTTPError
Bump utils to bring in recent changes to Template classes The main things we have to account for are: - `WithSubjectTemplate` has gone - every template dictionary must have `template_type` set
2020-04-15 17:58:57 +01:00
from notifications_utils.template import (
EmailPreviewTemplate,
LetterPreviewTemplate,
Fix preview of text messages on activity page Also beefs up the tests a bit so we can be more confident that the right thing is getting displayed. Depends on: - [ ] https://github.com/alphagov/notifications-utils/pull/725
2020-04-22 16:03:37 +01:00
SMSBodyPreviewTemplate,
Bump utils to bring in recent changes to Template classes The main things we have to account for are: - `WithSubjectTemplate` has gone - every template dictionary must have `template_type` set
2020-04-15 17:58:57 +01:00
)
Add login_required for all endpoints where it makes sense. https://www.pivotaltracker.com/story/show/111240834
2016-01-11 16:03:41 +00:00
Added current_service to flask context and template context. Fix all tests and conflicts. Removed comment line.
2016-04-04 16:53:52 +01:00
from app import (
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
current_service,
format_datetime_short,
Make one method for comma-formatting numbers We were doing this a few different ways in different places.
2019-07-08 14:09:29 +01:00
format_thousands,
Added current_service to flask context and template context. Fix all tests and conflicts. Removed comment line.
2016-04-04 16:53:52 +01:00
notification_api_client,
service_api_client,
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
)
Add messages to the current job’s history This mocks out a data structure for a job’s messages, and renders this data: - on the notification page, as a table, which links through to… - …the page for an indidivual message
2015-12-17 11:14:19 +00:00
from app.main import main
Add a form to filter notifications by recipient Because manually editing the URL isn’t a great user interface, this commit adds a search field to do this on the user’s behalf. For this pass at the story it doesn’t do any validation – the user will just get no results if they search by something which isn’t a phone number or email address. If the user navigates to a different ‘bucket’ of notifications (eg delivered, failed) then the search term is reset, because they’ve changed the filter which is at a level above the search term.
2017-05-30 13:51:25 +01:00
from app.main.forms import SearchNotificationsForm
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
from app.models.job import Job
Merge with master.
2016-03-29 22:50:40 +01:00
from app.utils import (
paginate jobs page (only views/jobs/jobs.html, which is the drill-down page, not the dashboard view)
2016-10-10 14:50:59 +01:00
generate_next_dict,
update tests to reflect new code also change jobs.py to filter out test jobs (since we dont need to see em) and to use the new statuses filter rather than filtering on front end
2016-10-05 17:45:04 +01:00
generate_notifications_csv,
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
generate_previous_dict,
Letter job can't be cancelled if already printed Non-cancellable letter statuses mean that it's too late to cancel a job
2019-06-18 18:00:36 +01:00
get_letter_printing_statement,
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
get_page_from_request,
get_time_left,
parse_filter_args,
Content changes for notification pages This commit adds content pages for the notifications pages, particularly the letter pages, which will make things clearer now that we will soon be allowing letters to be cancelled. The main changes are: * The confirmation banner for letters sent from a CSV file now states when printing will start. * We state the CSV file that notifications were sent from on the notifications page * The notification page for letters shows when printing starts (today, tomorrow, or that date that the letter was printed)
2018-11-27 16:49:01 +00:00
printing_today_or_tomorrow,
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
set_status_filters,
user_has_permissions,
A little refactoring
2018-01-12 12:06:07 +00:00
)
Make data consistent from dashboard -> job - adds a table of recent activity to the job page, which is shared by the dashboard page - uses the same filename and message template as the first job shown on the dashboard - sets the time of file uploads/message delivery/message sending to always match ‘just now’
2015-12-18 10:26:56 +00:00
Add messages to the current job’s history This mocks out a data structure for a job’s messages, and renders this data: - on the notification page, as a table, which links through to… - …the page for an indidivual message
2015-12-17 11:14:19 +00:00
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/jobs")
Let users with empty permissions see certain pages We’re going to make it possible for some users to be members of a service, but not have any permissions (not even `view_activity`). There are some pages that these users should still be able to see These are the pages that a user with ‘basic view’ would have been able to see, excluding those that let them send messages.
2018-08-06 11:09:57 +01:00
@user_has_permissions()
Work in progress, all tests passing and implemented mocks for services_dao.
2016-01-15 17:46:09 +00:00
def view_jobs(service_id):
Redirect the old jobs URL
2020-03-02 13:48:32 +00:00
return redirect(url_for(
'main.uploads',
service_id=current_service.id,
))
Add messages to the current job’s history This mocks out a data structure for a job’s messages, and renders this data: - on the notification page, as a table, which links through to… - …the page for an indidivual message
2015-12-17 11:14:19 +00:00
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/jobs/<uuid:job_id>")
Let users with empty permissions see certain pages We’re going to make it possible for some users to be members of a service, but not have any permissions (not even `view_activity`). There are some pages that these users should still be able to see These are the pages that a user with ‘basic view’ would have been able to see, excluding those that let them send messages.
2018-08-06 11:09:57 +01:00
@user_has_permissions()
Work in progress, all tests passing and implemented mocks for services_dao.
2016-01-15 17:46:09 +00:00
def view_job(service_id, job_id):
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 = Job.from_id(job_id, service_id=current_service.id)
if job.cancelled:
Don’t show cancelled jobs anywhere The information about a job doesn’t make sense if a job is cancelled. We could change the information to reflect that the job won’t be sent/ wasn’t sent/was cancelled, but there’s nothing you can really do with this info. So instead let’s: - hide cancelled jobs from the dashboard - hide cancelled jobs from the jobs page - 404 the page if the user tries to click back enough times to hit the job page
2016-09-01 15:46:16 +01:00
abort(404)
Put the download csv link on the activity page. Still needs some tests, probably some refactoring as well.
2017-12-30 16:54:39 +00:00
filter_args = parse_filter_args(request.args)
filter_args['status'] = set_status_filters(filter_args)
Derive markup dashboard from rendered partials This commit extends the `ajax_block` component to take a `dict` of partials, from which it can select the partial matching its `key` argument and print its HTML to the page. This means that the same markup is only rendered in one place, rather than in two (individually in the JSON endpoint and as `include`s in the parent template).
2016-06-28 11:23:43 +01:00
Make the formatting of postage times consistent Make the formatting of postage times consistent with the rest of the service, and the GOV.UK style guide.
2019-04-16 10:34:46 +01:00
just_sent_message = 'Your {} been sent. Printing starts {} at 5:30pm.'.format(
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
'letter has' if job.notification_count == 1 else 'letters have',
Group uploaded letters by day of printing Some teams have started uploading quite a lot of letters (in the hundreds per week). They’re also uploading CSVs of emails. This means the uploads page ends up quite jumbled. This is because: - there’s just a lot of items to scan through - conceptually it’s a bit odd to have batches of things displayed alongside individual things on the same page So instead we’re going to start grouping together uploaded letters. This will be by the date on which we ‘start’ printing them, or in other words the time at which they can no longer be cancelled. This feels like a natural grouping, and it matches what we know about people’s mental models of ‘batches’ and ‘runs’ when talking about printing. This grouping will be done in the API, so all this commit need to do is: - be ready to display this new type of pseudo-job - link to the page that displays all the uploaded letters for a given print day
2020-05-11 10:52:30 +01:00
printing_today_or_tomorrow(job.created_at)
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
)
Refactored register_errorhandlers so that it handles HTTPError Remove most cases where we catch HTTPError
2016-03-10 11:53:29 +00:00
return render_template(
'views/jobs/job.html',
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=job,
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
status=request.args.get('status', ''),
updates_url=url_for(
".view_job_updates",
service_id=service_id,
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_id=job.id,
Really hide the ‘download CSV’ link in the tour Tried to do this in https://github.com/alphagov/notifications-admin/pull/743 Didn’t account for it reappearing when the AJAX fired, because the AJAX request didn’t account for whether or not the user was in the tour.
2016-07-19 09:09:20 +01:00
status=request.args.get('status', ''),
Derive markup dashboard from rendered partials This commit extends the `ajax_block` component to take a `dict` of partials, from which it can select the partial matching its `key` argument and print its HTML to the page. This means that the same markup is only rendered in one place, rather than in two (individually in the JSON endpoint and as `include`s in the parent template).
2016-06-28 11:23:43 +01: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
partials=get_job_partials(job),
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
just_sent=request.args.get('just_sent') == 'yes',
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
just_sent_message=just_sent_message,
Refactored register_errorhandlers so that it handles HTTPError Remove most cases where we catch HTTPError
2016-03-10 11:53:29 +00:00
)
Add messages to the current job’s history This mocks out a data structure for a job’s messages, and renders this data: - on the notification page, as a table, which links through to… - …the page for an indidivual message
2015-12-17 11:14:19 +00:00
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/jobs/<uuid:job_id>.csv")
remove admin_override from all has_permissions usage as previously pointed out, it's not used anywhere.
2018-03-01 10:30:17 +00:00
@user_has_permissions('view_activity')
Use .csv extension not querystring parameter The link to download a CSV of notifications looks like `/endpoint?download=csv`. This not not very web idiomatic. The service manual recommends: > Only use query strings for URLs with unordered parameters like options > to search pages. The CSV is a different representation of the same data, it does not perform searching or filtering on the data. The proper way (as we do elsewhere in this app) is to put an extension on the endpoint to indicate an alternate representation, eg `/endpoint.csv`
2016-06-07 11:41:20 +01:00
def view_job_csv(service_id, job_id):
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 = Job.from_id(job_id, service_id=service_id)
Put the download csv link on the activity page. Still needs some tests, probably some refactoring as well.
2017-12-30 16:54:39 +00:00
filter_args = parse_filter_args(request.args)
filter_args['status'] = set_status_filters(filter_args)
Use .csv extension not querystring parameter The link to download a CSV of notifications looks like `/endpoint?download=csv`. This not not very web idiomatic. The service manual recommends: > Only use query strings for URLs with unordered parameters like options > to search pages. The CSV is a different representation of the same data, it does not perform searching or filtering on the data. The proper way (as we do elsewhere in this app) is to put an extension on the endpoint to indicate an alternate representation, eg `/endpoint.csv`
2016-06-07 11:41:20 +01:00
Return csv download stream instead of all-in-memory
2017-01-06 17:41:24 +00:00
return Response(
Add logging for streaming contents
2017-03-13 14:53:19 +00:00
stream_with_context(
generate_notifications_csv(
service_id=service_id,
job_id=job_id,
status=filter_args.get('status'),
page=request.args.get('page', 1),
Add extra flag to indicate we want a csv notification response
2017-04-20 14:57:31 +01:00
page_size=5000,
Add original file data to job downloads When downloading a report of a which messages from a job have been delivered and which have failed we currently only include the Notify data. This makes it hard to reconcile or do analysis on these reports, because often the thing that people want to reconcile on is in the data they’ve uploaded (eg a reference number). Here’s an example of a user talking about this problem: > It would also be helpful if the format of the delivery and failure > reports could include the fields from the recipient's file. While I > can, of course, cross-reference one report with the other it would be > easier if I did not have to. We send emails to individuals within > organisations and it is not always easy to establish the organisation > from a recipient's email address. This is particularly important when > emails fail to be delivered as we need to contact the organisation to > establish a new contact. – ticket 677 We’ve also seen it when doing research with a local council. This commit takes the original file, the data from the API, and munges them together.
2018-02-16 11:35:36 +00:00
format_for_csv=True,
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
template_type=job.template_type,
Add logging for streaming contents
2017-03-13 14:53:19 +00:00
)
Use .csv extension not querystring parameter The link to download a CSV of notifications looks like `/endpoint?download=csv`. This not not very web idiomatic. The service manual recommends: > Only use query strings for URLs with unordered parameters like options > to search pages. The CSV is a different representation of the same data, it does not perform searching or filtering on the data. The proper way (as we do elsewhere in this app) is to put an extension on the endpoint to indicate an alternate representation, eg `/endpoint.csv`
2016-06-07 11:41:20 +01:00
),
Return csv download stream instead of all-in-memory
2017-01-06 17:41:24 +00:00
mimetype='text/csv',
headers={
Use .csv extension not querystring parameter The link to download a CSV of notifications looks like `/endpoint?download=csv`. This not not very web idiomatic. The service manual recommends: > Only use query strings for URLs with unordered parameters like options > to search pages. The CSV is a different representation of the same data, it does not perform searching or filtering on the data. The proper way (as we do elsewhere in this app) is to put an extension on the endpoint to indicate an alternate representation, eg `/endpoint.csv`
2016-06-07 11:41:20 +01:00
'Content-Disposition': 'inline; filename="{} - {}.csv"'.format(
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.template['name'],
format_datetime_short(job.created_at)
Add logging for streaming contents
2017-03-13 14:53:19 +00:00
)
}
Use .csv extension not querystring parameter The link to download a CSV of notifications looks like `/endpoint?download=csv`. This not not very web idiomatic. The service manual recommends: > Only use query strings for URLs with unordered parameters like options > to search pages. The CSV is a different representation of the same data, it does not perform searching or filtering on the data. The proper way (as we do elsewhere in this app) is to put an extension on the endpoint to indicate an alternate representation, eg `/endpoint.csv`
2016-06-07 11:41:20 +01:00
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/jobs/<uuid:job_id>", methods=['POST'])
remove admin_override from all has_permissions usage as previously pointed out, it's not used anywhere.
2018-03-01 10:30:17 +00:00
@user_has_permissions('send_messages')
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
def cancel_job(service_id, job_id):
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.from_id(job_id, service_id=service_id).cancel()
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
return redirect(url_for('main.service_dashboard', service_id=service_id))
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/jobs/<uuid:job_id>/cancel", methods=['GET', 'POST'])
User can cancel a letter job - happy path
2019-06-18 15:52:29 +01:00
@user_has_permissions()
def cancel_letter_job(service_id, job_id):
if request.method == 'POST':
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 = Job.from_id(job_id, service_id=service_id)
if job.status != 'finished' or job.notifications_created < job.notification_count:
Can't cancel letter job if job not processed yet Also add more tests for showing or not the cancel those letters link Also check if all notifications already in database Upgrade delete button text logic to handle more cases Also corrections following review
2019-06-24 17:57:04 +01:00
flash("We are still processing these letters, please try again in a minute.", 'try again')
return view_job(service_id, job_id)
User can cancel a letter job - happy path
2019-06-18 15:52:29 +01:00
try:
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
number_of_letters = job.cancel()
User can cancel a letter job - happy path
2019-06-18 15:52:29 +01:00
except HTTPError as e:
flash(e.message, 'dangerous')
return redirect(url_for('main.view_job', service_id=service_id, job_id=job_id))
Make one method for comma-formatting numbers We were doing this a few different ways in different places.
2019-07-08 14:09:29 +01:00
flash("Cancelled {} letters from {}".format(
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
format_thousands(number_of_letters), job.original_file_name
Can't cancel letter job if job not processed yet Also add more tests for showing or not the cancel those letters link Also check if all notifications already in database Upgrade delete button text logic to handle more cases Also corrections following review
2019-06-24 17:57:04 +01:00
), 'default_with_tick')
User can cancel a letter job - happy path
2019-06-18 15:52:29 +01:00
return redirect(url_for('main.service_dashboard', service_id=service_id))
Can't cancel letter job if job not processed yet Also add more tests for showing or not the cancel those letters link Also check if all notifications already in database Upgrade delete button text logic to handle more cases Also corrections following review
2019-06-24 17:57:04 +01:00
flash("Are you sure you want to cancel sending these letters?", 'cancel')
User can cancel a letter job - happy path
2019-06-18 15:52:29 +01:00
return view_job(service_id, job_id)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/jobs/<uuid:job_id>.json")
Let users with empty permissions see certain pages We’re going to make it possible for some users to be members of a service, but not have any permissions (not even `view_activity`). There are some pages that these users should still be able to see These are the pages that a user with ‘basic view’ would have been able to see, excluding those that let them send messages.
2018-08-06 11:09:57 +01:00
@user_has_permissions()
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
def view_job_updates(service_id, job_id):
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
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 = Job.from_id(job_id, service_id=service_id)
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
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
return jsonify(**get_job_partials(job))
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
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route('/services/<uuid:service_id>/notifications', methods=['GET', 'POST'])
Add URL converters for template and file types Sometimes we manually check that a URL parameter is in a required set. Sometimes we don’t bother. This commit adds a URL converter to do this so that: - we don’t have to re-write the same code every time - it’s easier to apply this check to other endpoints This means endpoints that previously allowed a `template_type` or `message_type` of `None` now 404. So I’ve had to add new routes for with URLs that don’t include such parameters. So this…: ``` /services/128b91b6-2996-4107-bb65-51b7c24a728d/notifications/sms.csv /services/128b91b6-2996-4107-bb65-51b7c24a728d/notifications/None.csv ``` …becomes: ``` /services/128b91b6-2996-4107-bb65-51b7c24a728d/notifications/sms.csv /services/128b91b6-2996-4107-bb65-51b7c24a728d/notifications.csv ``` This matches what we do for the HTML-responding equivalent (see https://github.com/alphagov/notifications-admin/blob/265931d21746918c4ddfc19c4ad3f8cb5683c1bf/app/main/views/jobs.py#L215-L216)
2019-11-04 11:20:08 +00:00
@main.route('/services/<uuid:service_id>/notifications/<template_type:message_type>', methods=['GET', 'POST'])
Let users with empty permissions see certain pages We’re going to make it possible for some users to be members of a service, but not have any permissions (not even `view_activity`). There are some pages that these users should still be able to see These are the pages that a user with ‘basic view’ would have been able to see, excluding those that let them send messages.
2018-08-06 11:09:57 +01:00
@user_has_permissions()
Add sent notifications page for caseworkers The other task that caseworkers have to do (much less often than sending messages) is look at the messages which they’ve sent. The reason for doing this is usually to find a specific message which someone has complained about. This commit adds: - a page where they can do that - a navigation item so they can get to that page We reckon that because this is about finding specific messages, not reporting that it’s fine to mush all the channels (email, text, letter) into one table.
2018-06-13 14:16:10 +01:00
def view_notifications(service_id, message_type=None):
Make the activity page update with AJAX The activity page looks the same as the job page. So it should behave the same and not need manually refreshing to see the new stuff.
2016-09-27 15:07:40 +01:00
return render_template(
'views/notifications.html',
partials=get_notifications(service_id, message_type),
message_type=message_type,
Add a form to filter notifications by recipient Because manually editing the URL isn’t a great user interface, this commit adds a search field to do this on the user’s behalf. For this pass at the story it doesn’t do any validation – the user will just get no results if they search by something which isn’t a phone number or email address. If the user navigates to a different ‘bucket’ of notifications (eg delivered, failed) then the search term is reset, because they’ve changed the filter which is at a level above the search term.
2017-05-30 13:51:25 +01:00
status=request.args.get('status') or 'sending,delivered,failed',
Add query string parameter to search by recipient > Service teams that use the admin interface often need to know the > outcome of a message... at the moment they have to page through all > the results in the activity stream. They should be able to find > notifications by email address or phone number. – https://www.pivotaltracker.com/n/projects/1443052 This commit adds an additional query string parameter (`to`) to the URL, which users can use to filter down the list of notifications. It: - takes the status into account - doesn’t update the counts based on the search term (in reality each service will only send a handful of notifications to one person in any 7 day period) In other words the funnel that filters down the notifications looks like: > all notifications for service → only failed → only to this phone > number
2017-05-30 12:55:13 +01:00
page=request.args.get('page', 1),
Make search by recipient form POST not GET Phone numbers and email addresses are showing up in URLs where we let users search for sent notifications by phone number or email address. `GET` requests put the form data as a query string in the URL. This is problematic when people are searching by a recipient’s phone number or email address, because the URL may show up: - in our server logs - in our analytics - in the user’s browser history This is bad because these are all places where we don’t want people’s personal information. It’s not too bad when this is happening a handful of times. But it would be bad if we kept aggregating this information because it would allow us to track users across services. So, while it’s not especially RESTful, it’s better for the search form to submit as a `POST` request. This way the phone number or email address goes in the body of the request and does not show up in the URL.
2017-06-13 11:05:57 +01:00
to=request.form.get('to', ''),
Label the search box dependent on message type It doesn’t make sense to say ‘Search by email address or phone number’ when you’re only looking at emails.
2018-08-07 14:44:09 +01:00
search_form=SearchNotificationsForm(
message_type=message_type,
to=request.form.get('to', ''),
),
Tell users that they can search by reference Users who have an API integration (and therefore have a way of passing in a reference for each notification) can now search by that reference (see https://github.com/alphagov/notifications-api/pull/2682) This commit changes the label on the search box to tell these users that this is possible, without changing the label for users without an API integration, who might get confused by what ‘reference’ means. It also makes the label consistently say ‘email address or phone number’ (ie email address is first) because this is our content style.
2019-12-13 14:27:56 +00:00
things_you_can_search_by={
'email': ['email address'],
'sms': ['phone number'],
Let users search for letters Like we have search by email address or phone number, finding an individual letter is a common task. At the moment users are having to click through pages and pages of letters to find the one they’re looking for. Users of the API will also be able to search by reference, same as for emails and text messages. But we only show this hint text to users who have some API keys.
2020-04-21 13:55:23 +01:00
# This should become ‘postal address’ not ‘first line…’ once
# we’ve finished populating normalised addresses
'letter': ['first line of address', 'file name'],
# We say recipient here because combining all 3 types, plus
# reference gets too long for the hint text
None: ['recipient'],
Tell users that they can search by reference Users who have an API integration (and therefore have a way of passing in a reference for each notification) can now search by that reference (see https://github.com/alphagov/notifications-api/pull/2682) This commit changes the label on the search box to tell these users that this is possible, without changing the label for users without an API integration, who might get confused by what ‘reference’ means. It also makes the label consistently say ‘email address or phone number’ (ie email address is first) because this is our content style.
2019-12-13 14:27:56 +00:00
}.get(message_type) + {
True: ['reference'],
False: [],
}.get(bool(current_service.api_keys)),
Put the download csv link on the activity page. Still needs some tests, probably some refactoring as well.
2017-12-30 16:54:39 +00:00
download_link=url_for(
'.download_notifications_csv',
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
service_id=current_service.id,
Put the download csv link on the activity page. Still needs some tests, probably some refactoring as well.
2017-12-30 16:54:39 +00:00
message_type=message_type,
status=request.args.get('status')
)
Make the activity page update with AJAX The activity page looks the same as the job page. So it should behave the same and not need manually refreshing to see the new stuff.
2016-09-27 15:07:40 +01:00
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route('/services/<uuid:service_id>/notifications.json', methods=['GET', 'POST'])
Add URL converters for template and file types Sometimes we manually check that a URL parameter is in a required set. Sometimes we don’t bother. This commit adds a URL converter to do this so that: - we don’t have to re-write the same code every time - it’s easier to apply this check to other endpoints This means endpoints that previously allowed a `template_type` or `message_type` of `None` now 404. So I’ve had to add new routes for with URLs that don’t include such parameters. So this…: ``` /services/128b91b6-2996-4107-bb65-51b7c24a728d/notifications/sms.csv /services/128b91b6-2996-4107-bb65-51b7c24a728d/notifications/None.csv ``` …becomes: ``` /services/128b91b6-2996-4107-bb65-51b7c24a728d/notifications/sms.csv /services/128b91b6-2996-4107-bb65-51b7c24a728d/notifications.csv ``` This matches what we do for the HTML-responding equivalent (see https://github.com/alphagov/notifications-admin/blob/265931d21746918c4ddfc19c4ad3f8cb5683c1bf/app/main/views/jobs.py#L215-L216)
2019-11-04 11:20:08 +00:00
@main.route('/services/<uuid:service_id>/notifications/<template_type:message_type>.json', methods=['GET', 'POST'])
Let users with empty permissions see certain pages We’re going to make it possible for some users to be members of a service, but not have any permissions (not even `view_activity`). There are some pages that these users should still be able to see These are the pages that a user with ‘basic view’ would have been able to see, excluding those that let them send messages.
2018-08-06 11:09:57 +01:00
@user_has_permissions()
Add sent notifications page for caseworkers The other task that caseworkers have to do (much less often than sending messages) is look at the messages which they’ve sent. The reason for doing this is usually to find a specific message which someone has complained about. This commit adds: - a page where they can do that - a navigation item so they can get to that page We reckon that because this is about finding specific messages, not reporting that it’s fine to mush all the channels (email, text, letter) into one table.
2018-06-13 14:16:10 +01:00
def get_notifications_as_json(service_id, message_type=None):
Make the activity page update with AJAX The activity page looks the same as the job page. So it should behave the same and not need manually refreshing to see the new stuff.
2016-09-27 15:07:40 +01:00
return jsonify(get_notifications(
service_id, message_type, status_override=request.args.get('status')
))
Add URL converters for template and file types Sometimes we manually check that a URL parameter is in a required set. Sometimes we don’t bother. This commit adds a URL converter to do this so that: - we don’t have to re-write the same code every time - it’s easier to apply this check to other endpoints This means endpoints that previously allowed a `template_type` or `message_type` of `None` now 404. So I’ve had to add new routes for with URLs that don’t include such parameters. So this…: ``` /services/128b91b6-2996-4107-bb65-51b7c24a728d/notifications/sms.csv /services/128b91b6-2996-4107-bb65-51b7c24a728d/notifications/None.csv ``` …becomes: ``` /services/128b91b6-2996-4107-bb65-51b7c24a728d/notifications/sms.csv /services/128b91b6-2996-4107-bb65-51b7c24a728d/notifications.csv ``` This matches what we do for the HTML-responding equivalent (see https://github.com/alphagov/notifications-admin/blob/265931d21746918c4ddfc19c4ad3f8cb5683c1bf/app/main/views/jobs.py#L215-L216)
2019-11-04 11:20:08 +00:00
@main.route('/services/<uuid:service_id>/notifications.csv', endpoint="view_notifications_csv")
flake8
2019-11-29 13:03:23 +00:00
@main.route(
'/services/<uuid:service_id>/notifications/<template_type:message_type>.csv',
endpoint="view_notifications_csv"
)
Let users with empty permissions see certain pages We’re going to make it possible for some users to be members of a service, but not have any permissions (not even `view_activity`). There are some pages that these users should still be able to see These are the pages that a user with ‘basic view’ would have been able to see, excluding those that let them send messages.
2018-08-06 11:09:57 +01:00
@user_has_permissions()
Make the activity page update with AJAX The activity page looks the same as the job page. So it should behave the same and not need manually refreshing to see the new stuff.
2016-09-27 15:07:40 +01:00
def get_notifications(service_id, message_type, status_override=None):
Notification history page added and pagination, tests all working.
2016-03-16 16:57:10 +00:00
# TODO get the api to return count of pages as well.
page = get_page_from_request()
if page is None:
Raise error if getting complaints page with invalid page param If the `page` parameter passed to the `platform-admin/complaints` pageis not an integer, we should return a `404` error page.
2018-07-04 10:38:46 +01:00
abort(404, "Invalid page argument ({}).".format(request.args.get('page')))
Put the download csv link on the activity page. Still needs some tests, probably some refactoring as well.
2017-12-30 16:54:39 +00:00
filter_args = parse_filter_args(request.args)
filter_args['status'] = set_status_filters(filter_args)
Don’t ask for data retention unless channel is known If the user is looking at the notifications page for all message types (which is what we show ‘caseworkers’) then it doesn’t make sense to ask the API for the data retention period for that message type (because it will be `None`). Doing so causes the API to return a `404`, which then causes the admin app to return `404`. Passing through `None` as the value of limit days will just cause the API to return everything in the `notifications` table, which is fine for us.
2018-11-15 17:04:11 +00:00
service_data_retention_days = None
Don’t show pagination links when searching The search form makes a post request, so that phone numbers and email addresses don’t show up in logs or browser history. At most the API will return 50 results, with some pagination links. We can’t easily give you links to click in the admin app, because links can only perform get requests. Because the value of seeing more than 50 results feels quite low (users will probably make their search more specific before scrolling through all 50) let’s just show a message saying only the first 50 results are displayed.
2020-05-06 14:30:32 +01:00
search_term = request.form.get('to', '')
Use per-service data retention period to display notifications page Uses the configured service data retention page to display retention period length, notification counts and fetch notifications from the API on the notifications page.
2018-08-13 17:07:49 +01:00
Don’t ask for data retention unless channel is known If the user is looking at the notifications page for all message types (which is what we show ‘caseworkers’) then it doesn’t make sense to ask the API for the data retention period for that message type (because it will be `None`). Doing so causes the API to return a `404`, which then causes the admin app to return `404`. Passing through `None` as the value of limit days will just cause the API to return everything in the `notifications` table, which is fine for us.
2018-11-15 17:04:11 +00:00
if message_type is not None:
Add Service.get_days_of_retention helper method Data retention lookup by type is only performed to get the number of days, so we can update the service method to return the number or the default directly.
2018-12-03 17:57:11 +00:00
service_data_retention_days = current_service.get_days_of_retention(message_type)
Use per-service data retention period to display notifications page Uses the configured service data retention page to display retention period length, notification counts and fetch notifications from the API on the notifications page.
2018-08-13 17:07:49 +01:00
Don’t let caseworkers download CSV files No-one can at the moment, but when we bring the links back we should only bring them back for users who care about reporting and management information, ie those with the `view_activity` permission.
2018-06-13 14:13:39 +01:00
if request.path.endswith('csv') and current_user.has_permissions('view_activity'):
Refactor get notifications streaming including formatting
2017-01-13 11:35:27 +00:00
return Response(
generate_notifications_csv(
service_id=service_id,
page=page,
page_size=5000,
template_type=[message_type],
status=filter_args.get('status'),
Use per-service data retention period to display notifications page Uses the configured service data retention page to display retention period length, notification counts and fetch notifications from the API on the notifications page.
2018-08-13 17:07:49 +01:00
limit_days=service_data_retention_days
Refactor get notifications streaming including formatting
2017-01-13 11:35:27 +00:00
),
mimetype='text/csv',
headers={
'Content-Disposition': 'inline; filename="notifications.csv"'}
)
Working functionality for filtering notifications and all tests passing.
2016-04-04 16:34:06 +01:00
notifications = notification_api_client.get_notifications_for_service(
service_id=service_id,
page=page,
Add sent notifications page for caseworkers The other task that caseworkers have to do (much less often than sending messages) is look at the messages which they’ve sent. The reason for doing this is usually to find a specific message which someone has complained about. This commit adds: - a page where they can do that - a navigation item so they can get to that page We reckon that because this is about finding specific messages, not reporting that it’s fine to mush all the channels (email, text, letter) into one table.
2018-06-13 14:16:10 +01:00
template_type=[message_type] if message_type else [],
If user clicks failed or both filters for notifications status view, append all other failure states to query to api.
2016-05-18 11:44:58 +01:00
status=filter_args.get('status'),
Use per-service data retention period to display notifications page Uses the configured service data retention page to display retention period length, notification counts and fetch notifications from the API on the notifications page.
2018-08-13 17:07:49 +01:00
limit_days=service_data_retention_days,
Don’t show pagination links when searching The search form makes a post request, so that phone numbers and email addresses don’t show up in logs or browser history. At most the API will return 50 results, with some pagination links. We can’t easily give you links to click in the admin app, because links can only perform get requests. Because the value of seeing more than 50 results feels quite low (users will probably make their search more specific before scrolling through all 50) let’s just show a message saying only the first 50 results are displayed.
2020-05-06 14:30:32 +01:00
to=search_term,
Add query string parameter to search by recipient > Service teams that use the admin interface often need to know the > outcome of a message... at the moment they have to page through all > the results in the activity stream. They should be able to find > notifications by email address or phone number. – https://www.pivotaltracker.com/n/projects/1443052 This commit adds an additional query string parameter (`to`) to the URL, which users can use to filter down the list of notifications. It: - takes the status into account - doesn’t update the counts based on the search term (in reality each service will only send a handful of notifications to one person in any 7 day period) In other words the funnel that filters down the notifications looks like: > all notifications for service → only failed → only to this phone > number
2017-05-30 12:55:13 +01:00
)
paginate jobs page (only views/jobs/jobs.html, which is the drill-down page, not the dashboard view)
2016-10-10 14:50:59 +01:00
url_args = {
'message_type': message_type,
'status': request.args.get('status')
}
Notification history page added and pagination, tests all working.
2016-03-16 16:57:10 +00:00
prev_page = None
Refactor get notifications streaming including formatting
2017-01-13 11:35:27 +00:00
Add a form to filter notifications by recipient Because manually editing the URL isn’t a great user interface, this commit adds a search field to do this on the user’s behalf. For this pass at the story it doesn’t do any validation – the user will just get no results if they search by something which isn’t a phone number or email address. If the user navigates to a different ‘bucket’ of notifications (eg delivered, failed) then the search term is reset, because they’ve changed the filter which is at a level above the search term.
2017-05-30 13:51:25 +01:00
if 'links' in notifications and notifications['links'].get('prev', None):
add tests for new jobs functionality
2016-10-10 17:15:57 +01:00
prev_page = generate_previous_dict('main.view_notifications', service_id, page, url_args=url_args)
Notification history page added and pagination, tests all working.
2016-03-16 16:57:10 +00:00
next_page = None
Refactor get notifications streaming including formatting
2017-01-13 11:35:27 +00:00
Add a form to filter notifications by recipient Because manually editing the URL isn’t a great user interface, this commit adds a search field to do this on the user’s behalf. For this pass at the story it doesn’t do any validation – the user will just get no results if they search by something which isn’t a phone number or email address. If the user navigates to a different ‘bucket’ of notifications (eg delivered, failed) then the search term is reset, because they’ve changed the filter which is at a level above the search term.
2017-05-30 13:51:25 +01:00
if 'links' in notifications and notifications['links'].get('next', None):
add tests for new jobs functionality
2016-10-10 17:15:57 +01:00
next_page = generate_next_dict('main.view_notifications', service_id, page, url_args)
paginate jobs page (only views/jobs/jobs.html, which is the drill-down page, not the dashboard view)
2016-10-10 14:50:59 +01:00
Add sent notifications page for caseworkers The other task that caseworkers have to do (much less often than sending messages) is look at the messages which they’ve sent. The reason for doing this is usually to find a specific message which someone has complained about. This commit adds: - a page where they can do that - a navigation item so they can get to that page We reckon that because this is about finding specific messages, not reporting that it’s fine to mush all the channels (email, text, letter) into one table.
2018-06-13 14:16:10 +01:00
if message_type:
download_link = url_for(
'.view_notifications_csv',
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
service_id=current_service.id,
Add sent notifications page for caseworkers The other task that caseworkers have to do (much less often than sending messages) is look at the messages which they’ve sent. The reason for doing this is usually to find a specific message which someone has complained about. This commit adds: - a page where they can do that - a navigation item so they can get to that page We reckon that because this is about finding specific messages, not reporting that it’s fine to mush all the channels (email, text, letter) into one table.
2018-06-13 14:16:10 +01:00
message_type=message_type,
status=request.args.get('status')
)
else:
download_link = None
Make the activity page update with AJAX The activity page looks the same as the job page. So it should behave the same and not need manually refreshing to see the new stuff.
2016-09-27 15:07:40 +01:00
return {
Use per-service data retention period to display notifications page Uses the configured service data retention page to display retention period length, notification counts and fetch notifications from the API on the notifications page.
2018-08-13 17:07:49 +01:00
'service_data_retention_days': service_data_retention_days,
Make the activity page update with AJAX The activity page looks the same as the job page. So it should behave the same and not need manually refreshing to see the new stuff.
2016-09-27 15:07:40 +01:00
'counts': render_template(
'views/activity/counts.html',
status=request.args.get('status'),
status_filters=get_status_filters(
current_service,
message_type,
Use per-service data retention period to display notifications page Uses the configured service data retention page to display retention period length, notification counts and fetch notifications from the API on the notifications page.
2018-08-13 17:07:49 +01:00
service_api_client.get_service_statistics(
service_id,
today_only=False,
limit_days=service_data_retention_days
)
Make the activity page update with AJAX The activity page looks the same as the job page. So it should behave the same and not need manually refreshing to see the new stuff.
2016-09-27 15:07:40 +01:00
)
),
'notifications': render_template(
'views/activity/notifications.html',
Refactor content preview method into generator This will let us break up this method a bit more, rather than make the dictionary comprehension even more involved and nested. Means we need to `list()` it, because generator expressions cast to boolean are `True`, even if they’re empty – Python doesn’t evaluate them. ie: ```python bool(list()) >>> False ``` ```python bool((item for item in list())) >>> True ``` ```python bool(list(item for item in list())) >>> False ```
2017-06-24 17:20:00 +01:00
notifications=list(add_preview_of_content_to_notifications(
notifications['notifications']
)),
Make the activity page update with AJAX The activity page looks the same as the job page. So it should behave the same and not need manually refreshing to see the new stuff.
2016-09-27 15:07:40 +01:00
page=page,
Use per-service data retention period to display notifications page Uses the configured service data retention page to display retention period length, notification counts and fetch notifications from the API on the notifications page.
2018-08-13 17:07:49 +01:00
limit_days=service_data_retention_days,
Make the activity page update with AJAX The activity page looks the same as the job page. So it should behave the same and not need manually refreshing to see the new stuff.
2016-09-27 15:07:40 +01:00
prev_page=prev_page,
next_page=next_page,
Change logic around to be clearer Think this is a clearer expression of what the intent it.
2020-05-07 09:50:03 +01:00
show_pagination=(not search_term),
Make the activity page update with AJAX The activity page looks the same as the job page. So it should behave the same and not need manually refreshing to see the new stuff.
2016-09-27 15:07:40 +01:00
status=request.args.get('status'),
Use .csv extension not querystring parameter The link to download a CSV of notifications looks like `/endpoint?download=csv`. This not not very web idiomatic. The service manual recommends: > Only use query strings for URLs with unordered parameters like options > to search pages. The CSV is a different representation of the same data, it does not perform searching or filtering on the data. The proper way (as we do elsewhere in this app) is to put an extension on the endpoint to indicate an alternate representation, eg `/endpoint.csv`
2016-06-07 11:41:20 +01:00
message_type=message_type,
Add sent notifications page for caseworkers The other task that caseworkers have to do (much less often than sending messages) is look at the messages which they’ve sent. The reason for doing this is usually to find a specific message which someone has complained about. This commit adds: - a page where they can do that - a navigation item so they can get to that page We reckon that because this is about finding specific messages, not reporting that it’s fine to mush all the channels (email, text, letter) into one table.
2018-06-13 14:16:10 +01:00
download_link=download_link,
Link back to uploaded letters page If you’ve come to look at a notification via the uploaded letters page then the ‘< back’ link should take you back there, not to the usual activity page.
2020-05-11 14:20:53 +01:00
single_notification_url=partial(
url_for,
'.view_notification',
service_id=current_service.id,
)
Use .csv extension not querystring parameter The link to download a CSV of notifications looks like `/endpoint?download=csv`. This not not very web idiomatic. The service manual recommends: > Only use query strings for URLs with unordered parameters like options > to search pages. The CSV is a different representation of the same data, it does not perform searching or filtering on the data. The proper way (as we do elsewhere in this app) is to put an extension on the endpoint to indicate an alternate representation, eg `/endpoint.csv`
2016-06-07 11:41:20 +01:00
),
Make the activity page update with AJAX The activity page looks the same as the job page. So it should behave the same and not need manually refreshing to see the new stuff.
2016-09-27 15:07:40 +01:00
}
Notification history page added and pagination, tests all working.
2016-03-16 16:57:10 +00:00
use detailed service endpoint in notification summary page to help get rid of notification statistics tables, move over the job page. fortunately its required data format is almost identical to the return value of the detailed service endpoint, so little work is required - only to add a sending column
2016-07-20 15:19:58 +01:00
def get_status_filters(service, message_type, statistics):
Add sent notifications page for caseworkers The other task that caseworkers have to do (much less often than sending messages) is look at the messages which they’ve sent. The reason for doing this is usually to find a specific message which someone has complained about. This commit adds: - a page where they can do that - a navigation item so they can get to that page We reckon that because this is about finding specific messages, not reporting that it’s fine to mush all the channels (email, text, letter) into one table.
2018-06-13 14:16:10 +01:00
if message_type is None:
stats = {
key: sum(
statistics[message_type][key]
for message_type in {'email', 'sms', 'letter'}
)
for key in {'requested', 'delivered', 'failed'}
}
else:
stats = statistics[message_type]
use detailed service endpoint in notification summary page to help get rid of notification statistics tables, move over the job page. fortunately its required data format is almost identical to the return value of the detailed service endpoint, so little work is required - only to add a sending column
2016-07-20 15:19:58 +01:00
stats['sending'] = stats['requested'] - stats['delivered'] - stats['failed']
filters = [
# key, label, option
Change ‘processed’ to ‘total’ Processed is not an easy to understand thing, and the overlap with sending/delivered/failed is not easy to intuit. ‘Total’ is a much easier concept to grasp (it relates directly to your file), and it’s less distracting because it doesn’t change.
2016-08-03 09:47:27 +01:00
('requested', 'total', 'sending,delivered,failed'),
use detailed service endpoint in notification summary page to help get rid of notification statistics tables, move over the job page. fortunately its required data format is almost identical to the return value of the detailed service endpoint, so little work is required - only to add a sending column
2016-07-20 15:19:58 +01:00
('sending', 'sending', 'sending'),
('delivered', 'delivered', 'delivered'),
('failed', 'failed', 'failed'),
]
return [
# return list containing label, option, link, count
(
label,
option,
url_for(
'.view_notifications',
Don’t allow indexing on service model Making people use a property is a sure way to make sure they’re spelling the name of the property correctly, and allows us to easily swap out properties that call through to the underlying JSON, and properties which are implemented as methods.
2018-10-26 12:13:04 +01:00
service_id=service.id,
use detailed service endpoint in notification summary page to help get rid of notification statistics tables, move over the job page. fortunately its required data format is almost identical to the return value of the detailed service endpoint, so little work is required - only to add a sending column
2016-07-20 15:19:58 +01:00
message_type=message_type,
status=option
),
stats[key]
)
for key, label, option in filters
Return csv download stream instead of all-in-memory
2017-01-06 17:41:24 +00:00
]
use detailed service endpoint in notification summary page to help get rid of notification statistics tables, move over the job page. fortunately its required data format is almost identical to the return value of the detailed service endpoint, so little work is required - only to add a sending column
2016-07-20 15:19:58 +01:00
Remove tour-related stuff from the job page The tour does the send one-off thing now, rather than creating a job.
2017-07-03 15:43:28 +01:00
def _get_job_counts(job):
Make jobs filterable by notification status We can filter all notifications by status already. This commit reuses the same code to filter the notifications for a job by status. This means that, visually we can show the count on a job the same as we do for all notifications, which is similar to how we show the counts on the dashboard, so hopefully it feels like a bit more of a solid thing. This also applies to CSV downloads and AJAX updates, which will inherit any filtering that their parent page has applied.
2016-06-08 16:34:26 +01:00
return [
(
label,
query_param,
url_for(
".view_job",
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
service_id=job.service,
job_id=job.id,
Make jobs filterable by notification status We can filter all notifications by status already. This commit reuses the same code to filter the notifications for a job by status. This means that, visually we can show the count on a job the same as we do for all notifications, which is similar to how we show the counts on the dashboard, so hopefully it feels like a bit more of a solid thing. This also applies to CSV downloads and AJAX updates, which will inherit any filtering that their parent page has applied.
2016-06-08 16:34:26 +01:00
status=query_param,
),
count
) for label, query_param, count in [
[
Simplified the config files for admin.
2016-09-07 10:31:33 +01:00
'total', '',
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.notification_count
Make jobs filterable by notification status We can filter all notifications by status already. This commit reuses the same code to filter the notifications for a job by status. This means that, visually we can show the count on a job the same as we do for all notifications, which is similar to how we show the counts on the dashboard, so hopefully it feels like a bit more of a solid thing. This also applies to CSV downloads and AJAX updates, which will inherit any filtering that their parent page has applied.
2016-06-08 16:34:26 +01:00
],
[
Simplified the config files for admin.
2016-09-07 10:31:33 +01:00
'sending', 'sending',
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.notifications_sending
Make jobs filterable by notification status We can filter all notifications by status already. This commit reuses the same code to filter the notifications for a job by status. This means that, visually we can show the count on a job the same as we do for all notifications, which is similar to how we show the counts on the dashboard, so hopefully it feels like a bit more of a solid thing. This also applies to CSV downloads and AJAX updates, which will inherit any filtering that their parent page has applied.
2016-06-08 16:34:26 +01:00
],
[
Simplified the config files for admin.
2016-09-07 10:31:33 +01:00
'delivered', 'delivered',
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.notifications_delivered
Make jobs filterable by notification status We can filter all notifications by status already. This commit reuses the same code to filter the notifications for a job by status. This means that, visually we can show the count on a job the same as we do for all notifications, which is similar to how we show the counts on the dashboard, so hopefully it feels like a bit more of a solid thing. This also applies to CSV downloads and AJAX updates, which will inherit any filtering that their parent page has applied.
2016-06-08 16:34:26 +01:00
],
[
Simplified the config files for admin.
2016-09-07 10:31:33 +01:00
'failed', 'failed',
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.notifications_failed
Make jobs filterable by notification status We can filter all notifications by status already. This commit reuses the same code to filter the notifications for a job by status. This means that, visually we can show the count on a job the same as we do for all notifications, which is similar to how we show the counts on the dashboard, so hopefully it feels like a bit more of a solid thing. This also applies to CSV downloads and AJAX updates, which will inherit any filtering that their parent page has applied.
2016-06-08 16:34:26 +01:00
]
]
Removed unused route and fixed some formatting
2016-09-08 09:29:08 +01:00
]
Derive markup dashboard from rendered partials This commit extends the `ajax_block` component to take a `dict` of partials, from which it can select the partial matching its `key` argument and print its HTML to the page. This means that the same markup is only rendered in one place, rather than in two (individually in the JSON endpoint and as `include`s in the parent template).
2016-06-28 11:23:43 +01: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
def get_job_partials(job):
Put the download csv link on the activity page. Still needs some tests, probably some refactoring as well.
2017-12-30 16:54:39 +00:00
filter_args = parse_filter_args(request.args)
filter_args['status'] = set_status_filters(filter_args)
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
notifications = job.get_notifications(status=filter_args['status'])
if job.template_type == 'letter':
Replace blue boxes with total + delivery estimate The sending/failed/delivered thing: - doesn’t map to the actual states of letters - doesn’t respond quickly enough to give you feedback that something is happening (because "sending" doesn’t even go to "probably delivered" for a few days) This commit replaces these 4 boxes with some more useful information: - one number – how many letters were in the job in total - when we estimate that the letters will be delivered
2017-07-13 07:09:33 +01:00
counts = render_template(
'partials/jobs/count-letters.html',
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=job,
Replace blue boxes with total + delivery estimate The sending/failed/delivered thing: - doesn’t map to the actual states of letters - doesn’t respond quickly enough to give you feedback that something is happening (because "sending" doesn’t even go to "probably delivered" for a few days) This commit replaces these 4 boxes with some more useful information: - one number – how many letters were in the job in total - when we estimate that the letters will be delivered
2017-07-13 07:09:33 +01:00
)
else:
counts = render_template(
add add one-off notification status completely mimicks the job status page, and as such, all the code and templates have been taken from the job page. This page performs exactly the same as the job page for now * total, sending, delivered, failed blue boxes (though they'll just read 0/1 for now. * download report button (same as with job download, except without job or row number in file) * removed references to scheduled * kept references to help (aka tour/tutorial) as that'll eventually change over from a job to a one-off too
2017-06-12 17:21:25 +01:00
'partials/count.html',
Remove tour-related stuff from the job page The tour does the send one-off thing now, rather than creating a job.
2017-07-03 15:43:28 +01:00
counts=_get_job_counts(job),
Don’t show blue boxes once notifications have gone You can click the blue boxes to filter the list of notifications. Once the notifications have gone there’s nothing to filter, so we should just show the numbers but without them being clickable.
2019-12-30 16:53:45 +00:00
status=filter_args['status'],
notifications_deleted=(
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.status == 'finished' and not notifications['notifications']
Don’t show blue boxes once notifications have gone You can click the blue boxes to filter the list of notifications. Once the notifications have gone there’s nothing to filter, so we should just show the numbers but without them being clickable.
2019-12-30 16:53:45 +00:00
),
Replace blue boxes with total + delivery estimate The sending/failed/delivered thing: - doesn’t map to the actual states of letters - doesn’t respond quickly enough to give you feedback that something is happening (because "sending" doesn’t even go to "probably delivered" for a few days) This commit replaces these 4 boxes with some more useful information: - one number – how many letters were in the job in total - when we estimate that the letters will be delivered
2017-07-13 07:09:33 +01: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
service_data_retention_days = current_service.get_days_of_retention(job.template_type)
Replace blue boxes with total + delivery estimate The sending/failed/delivered thing: - doesn’t map to the actual states of letters - doesn’t respond quickly enough to give you feedback that something is happening (because "sending" doesn’t even go to "probably delivered" for a few days) This commit replaces these 4 boxes with some more useful information: - one number – how many letters were in the job in total - when we estimate that the letters will be delivered
2017-07-13 07:09:33 +01:00
return {
'counts': counts,
Derive markup dashboard from rendered partials This commit extends the `ajax_block` component to take a `dict` of partials, from which it can select the partial matching its `key` argument and print its HTML to the page. This means that the same markup is only rendered in one place, rather than in two (individually in the JSON endpoint and as `include`s in the parent template).
2016-06-28 11:23:43 +01:00
'notifications': render_template(
'partials/jobs/notifications.html',
Revert "Merge pull request #1336 from alphagov/revert-show-notifications" This reverts commit 7e354ff341172041d6141b50833af6262308fcb4, reversing changes made to 6f3bcff32fbfc78b4df0558d08605a260786112f.
2017-06-24 17:12:45 +01:00
notifications=list(
add_preview_of_content_to_notifications(notifications['notifications'])
),
Don’t show the download until the job is complete The CSV report isn’t very useful until it has all the rows from your original file. So we shouldn’t show you the link until all notifications have been created. Until this point, it’s useful to know how much longer you need to wait, so this commit adds a percentage count of how much of the file has been processed.
2016-08-02 21:27:23 +01:00
more_than_one_page=bool(notifications.get('links', {}).get('next')),
Don’t pass entire job thru to notifications page It only needs the `id`, and it only needs that to generate the download URL, so let’s just pass the URL through instead.
2016-07-18 09:04:43 +01:00
download_link=url_for(
'.view_job_csv',
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
service_id=current_service.id,
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_id=job.id,
Don’t let _set_status_filters mutate original list Mutating stuff is scary and prone to problems. Better for it to return a new list instead.
2016-08-05 10:18:27 +01:00
status=request.args.get('status')
Don’t pass entire job thru to notifications page It only needs the `id`, and it only needs that to generate the download URL, so let’s just pass the URL through instead.
2016-07-18 09:04:43 +01: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
time_left=get_time_left(job.created_at, service_data_retention_days=service_data_retention_days),
Revert "Merge pull request #1336 from alphagov/revert-show-notifications" This reverts commit 7e354ff341172041d6141b50833af6262308fcb4, reversing changes made to 6f3bcff32fbfc78b4df0558d08605a260786112f.
2017-06-24 17:12:45 +01:00
job=job,
Add a more accurate missing notifications message Notifications could be missing because: - none have been created yet - they’ve been deleted This commit adds separate error messages for each case, rather than a less helpful generic one.
2019-12-30 16:37:50 +00:00
service_data_retention_days=service_data_retention_days,
Derive markup dashboard from rendered partials This commit extends the `ajax_block` component to take a `dict` of partials, from which it can select the partial matching its `key` argument and print its HTML to the page. This means that the same markup is only rendered in one place, rather than in two (individually in the JSON endpoint and as `include`s in the parent template).
2016-06-28 11:23:43 +01:00
),
'status': render_template(
'partials/jobs/status.html',
Letter job can't be cancelled if already printed Non-cancellable letter statuses mean that it's too late to cancel a job
2019-06-18 18:00:36 +01:00
job=job,
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
letter_print_day=get_letter_printing_statement("created", job.created_at)
Derive markup dashboard from rendered partials This commit extends the `ajax_block` component to take a `dict` of partials, from which it can select the partial matching its `key` argument and print its HTML to the page. This means that the same markup is only rendered in one place, rather than in two (individually in the JSON endpoint and as `include`s in the parent template).
2016-06-28 11:23:43 +01:00
),
}
Revert "Merge pull request #1336 from alphagov/revert-show-notifications" This reverts commit 7e354ff341172041d6141b50833af6262308fcb4, reversing changes made to 6f3bcff32fbfc78b4df0558d08605a260786112f.
2017-06-24 17:12:45 +01:00
def add_preview_of_content_to_notifications(notifications):
Respect template’s redaction preference If a template has the `redact_personalisation` flag set, then this commit removes the personalisation from the notification before rehydrating the template. We’re doing this because we have a need to not show things like one time passwords or two factor codes when we show the content of messages. By passing through empty personalisation, and the `redact_missing` flag, the `Template` instance will make use of the work done in: - [x] https://github.com/alphagov/notifications-utils/pull/171
2017-06-24 17:29:28 +01:00
Refactor content preview method into generator This will let us break up this method a bit more, rather than make the dictionary comprehension even more involved and nested. Means we need to `list()` it, because generator expressions cast to boolean are `True`, even if they’re empty – Python doesn’t evaluate them. ie: ```python bool(list()) >>> False ``` ```python bool((item for item in list())) >>> True ``` ```python bool(list(item for item in list())) >>> False ```
2017-06-24 17:20:00 +01:00
for notification in notifications:
Bump utils to bring in recent changes to Template classes The main things we have to account for are: - `WithSubjectTemplate` has gone - every template dictionary must have `template_type` set
2020-04-15 17:58:57 +01:00
yield(dict(
preview_of_content=get_preview_of_content(notification),
**notification
))
def get_preview_of_content(notification):
if notification['template'].get('redact_personalisation'):
notification['personalisation'] = {}
if notification['template']['is_precompiled_letter']:
return notification['client_reference']
if notification['template']['template_type'] == 'sms':
Fix preview of text messages on activity page Also beefs up the tests a bit so we can be more confident that the right thing is getting displayed. Depends on: - [ ] https://github.com/alphagov/notifications-utils/pull/725
2020-04-22 16:03:37 +01:00
return str(SMSBodyPreviewTemplate(
Bump utils to bring in recent changes to Template classes The main things we have to account for are: - `WithSubjectTemplate` has gone - every template dictionary must have `template_type` set
2020-04-15 17:58:57 +01:00
notification['template'],
notification['personalisation'],
))
if notification['template']['template_type'] == 'email':
return EmailPreviewTemplate(
notification['template'],
notification['personalisation'],
redact_missing_personalisation=True,
).subject
if notification['template']['template_type'] == 'letter':
return LetterPreviewTemplate(
notification['template'],
notification['personalisation'],
).subject
Reference in New Issue Copy Permalink