darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2025-12-16 01:53:56 -05:00
Code Issues Packages Projects Releases Wiki Activity
Files
a602ffceb94b47f2370948b8777cf6d969326514
notifications-admin/app/models/job.py

252 lines
7.2 KiB
Python
Raw Normal View History

Refactor to use shared date comparison function This means we don’t have to repeatedly do timezone conversions or string to datetime conversions in our business logic.
2020-09-29 13:17:12 +01:00
from datetime import timedelta
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
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
import pytz
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 notifications_utils.letter_timings import (
CANCELLABLE_JOB_LETTER_STATUSES,
get_letter_timings,
letter_can_be_cancelled,
)
Refactor to use shared date comparison function This means we don’t have to repeatedly do timezone conversions or string to datetime conversions in our business logic.
2020-09-29 13:17:12 +01:00
from notifications_utils.timezones import utc_string_to_aware_gmt_datetime
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 werkzeug.utils import cached_property
Refactor to make pagination reusable The responses we get to paginated queries from the API are fairly consistent, so we should be able to reuse the code that takes JSON from the API and turns it into Python objects. This commits factors out that code so that it is reusable (by inheriting from it).
2020-05-12 17:06:23 +01:00
from app.models import JSONModel, ModelList, PaginatedModelList
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.notify_client.job_api_client import job_api_client
from app.notify_client.notification_api_client import notification_api_client
from app.notify_client.service_api_client import service_api_client
DRY-up email revalidation check Previously this was duplicated between the "two_factor" and the "webauthn" views, and required more test setup. This DRYs up the check and tests it once, using mocks to simplify the view tests. As part of DRYing up the check into a util module, I've also moved the "is_less_than_days_ago" function it uses.
2021-06-14 12:40:12 +01:00
from app.utils import set_status_filters
Extract letter utility code into own module This provides more room for expansion, and reduces the amount of arbitrary code in the __init__.py file for the new package.
2021-06-09 13:59:06 +01:00
from app.utils.letters import get_letter_printing_statement
DRY-up email revalidation check Previously this was duplicated between the "two_factor" and the "webauthn" views, and required more test setup. This DRYs up the check and tests it once, using mocks to simplify the view tests. As part of DRYing up the check into a util module, I've also moved the "is_less_than_days_ago" function it uses.
2021-06-14 12:40:12 +01:00
from app.utils.time import is_less_than_days_ago
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
class Job(JSONModel):
ALLOWED_PROPERTIES = {
'id',
'service',
Refactor to make pagination reusable The responses we get to paginated queries from the API are fairly consistent, so we should be able to reuse the code that takes JSON from the API and turns it into Python objects. This commits factors out that code so that it is reusable (by inheriting from it).
2020-05-12 17:06:23 +01:00
'template_name',
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_version',
'original_file_name',
'created_at',
'notification_count',
'created_by',
Use template_type property directly from API It’s included in the job/upload response now[1]. So we don’t need to fetch the template every time we want to access it. 1. https://github.com/alphagov/notifications-api/pull/2728
2020-02-27 10:13:10 +00:00
'template_type',
Differentiate between different kinds of uploads Knowing what kind of upload a thing is is useful. And the information that is useful to show about each upload depends on what kind of upload it is.
2020-02-27 14:03:03 +00:00
'recipient',
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
}
@classmethod
def from_id(cls, job_id, service_id):
return cls(job_api_client.get_job(service_id, job_id)['data'])
@property
def status(self):
Don’t assume jobs status will be present The API response for jobs includes a field called `job_status`. The API response for uploads doesn’t. The `Job` mode handles uploads and jobs, so it needs to account for the possibility of the field not being there.
2020-01-20 15:25:47 +00:00
return self._dict.get('job_status')
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
@property
def cancelled(self):
return self.status == 'cancelled'
@property
def scheduled(self):
return self.status == 'scheduled'
Account for missing scheduled for field Jobs have a `scheduled_for` field. Single letter uploads don’t. At the moment we treat both of them as `Job`s. So the `Job` model needs to account for when the `scheduled_for` field is missing.
2020-01-17 10:01:39 +00:00
@property
def scheduled_for(self):
return self._dict.get('scheduled_for')
Add upload_type property to Job class
2020-02-04 15:36:55 +00:00
@property
def upload_type(self):
return self._dict.get('upload_type')
Differentiate between different kinds of uploads Knowing what kind of upload a thing is is useful. And the information that is useful to show about each upload depends on what kind of upload it is.
2020-02-27 14:03:03 +00:00
@property
def pdf_letter(self):
return self.upload_type == 'letter'
Use time to determine why notifications don’t exist Notifications won’t exist for a job if: - it’s just started - it started a long time ago (older than the retention period) We have a bug where: 1. Job starts processing, puts notifications on queue 2. Job finishes processing, sets status to `finished` 3. First notification gets picked up off the queue and put in the database In between 2. and 3. it’s possible for a job to be finished, but also to have no notifications. We’re saying this is because the notifications have been deleted, whereas really it’s because they haven’t been created yet. This commit fixes that bug by introducing the concept of recency for jobs. ‘Recent’ is defined as 1 day, which is: - a lot longer than it takes to create any notifications - a bit shorter than anyone’s retention time N.B. `processing_started` is defined here: https://github.com/alphagov/notifications-api/blob/879ba1d5f092dbf6e15bf9adadd53e4657660490/app/models.py#L1194 It can be `None` for scheduled jobs that haven’t started yet.
2020-01-16 16:58:26 +00:00
@property
def processing_started(self):
if not self._dict.get('processing_started'):
return None
Fix incorrect processing started time on jobs We were doing the UTC to BST conversion twice, meaning the job was shown as being started 2 hours later than UTC, and 1 hour later than actual BST.
2020-09-28 14:53:42 +01:00
return self._dict['processing_started']
Use time to determine why notifications don’t exist Notifications won’t exist for a job if: - it’s just started - it started a long time ago (older than the retention period) We have a bug where: 1. Job starts processing, puts notifications on queue 2. Job finishes processing, sets status to `finished` 3. First notification gets picked up off the queue and put in the database In between 2. and 3. it’s possible for a job to be finished, but also to have no notifications. We’re saying this is because the notifications have been deleted, whereas really it’s because they haven’t been created yet. This commit fixes that bug by introducing the concept of recency for jobs. ‘Recent’ is defined as 1 day, which is: - a lot longer than it takes to create any notifications - a bit shorter than anyone’s retention time N.B. `processing_started` is defined here: https://github.com/alphagov/notifications-api/blob/879ba1d5f092dbf6e15bf9adadd53e4657660490/app/models.py#L1194 It can be `None` for scheduled jobs that haven’t started yet.
2020-01-16 16:58:26 +00:00
Refactor again
2020-01-09 15:54:42 +00:00
def _aggregate_statistics(self, *statuses):
Refactor stats calcualtions
2020-01-09 15:52:19 +00:00
return sum(
outcome['count'] for outcome in self._dict['statistics']
Refactor again
2020-01-09 15:54:42 +00:00
if not statuses or outcome['status'] in statuses
Refactor stats calcualtions
2020-01-09 15:52:19 +00:00
)
Make a job model for individual jobs This follows the pattern of what we’ve done with services, users and events. It gives us a better interface to the data we get back from the API than dealing with the raw JSON directly. Now is a good time to do this because we’re going to be making a bunch of changes to the jobs pages, and those changes will be easier to code and understand with a sesnsible model behind them.
2020-01-08 12:23:09 +00:00
Refactor again
2020-01-09 15:54:42 +00:00
@property
def notifications_delivered(self):
return self._aggregate_statistics('delivered', 'sent')
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
@property
def notifications_failed(self):
Refactor again
2020-01-09 15:54:42 +00:00
return self._aggregate_statistics(
'failed', 'technical-failure', 'temporary-failure',
'permanent-failure', 'cancelled',
Refactor stats calcualtions
2020-01-09 15:52:19 +00:00
)
Move stats to the model The API clients should just deal with calling the API and returning the data from it. Inferring things from the data is more logically done at the model layer. But we couldn’t do that before, because we didn’t have a model layer for jobs.
2020-01-08 16:32:08 +00:00
@property
def notifications_requested(self):
Refactor again
2020-01-09 15:54:42 +00:00
return self._aggregate_statistics()
Move stats to the model The API clients should just deal with calling the API and returning the data from it. Inferring things from the data is more logically done at the model layer. But we couldn’t do that before, because we didn’t have a model layer for jobs.
2020-01-08 16:32:08 +00:00
@property
def notifications_sent(self):
return self.notifications_delivered + self.notifications_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
@property
def notifications_sending(self):
if self.scheduled:
return 0
Move stats to the model The API clients should just deal with calling the API and returning the data from it. Inferring things from the data is more logically done at the model layer. But we couldn’t do that before, because we didn’t have a model layer for jobs.
2020-01-08 16:32:08 +00:00
return self.notification_count - self.notifications_sent
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
@property
def notifications_created(self):
return notification_api_client.get_notification_count_for_job_id(
service_id=self.service, job_id=self.id
)
@property
def still_processing(self):
return (
fix bug where job reports showed before jobs finished for a job to be finished there are two requirements: * the status to be "finished" * the percentage complete to be 100% The job status is set to finished when the process_job task finishes (even though not all process_row may have finished). The percentage_complete is calculated by comparing the number of notifications in the database with the number of rows in the spreadsheet. This was inadvertently changed from an "and" to an "or" clause two years ago. This meant that people could download a report when the status was finished but not all notifications were present in the database. Lets change it back. https://github.com/alphagov/notifications-admin/commit/7d52ac97f111f6538b5cbe5cae1d369aac30cd04#diff-44b012cad205379c481bed244ddb2294bae5ee85dcd01f4aee932a2bd85b67b2L86-R100
2022-01-14 12:41:01 +00:00
self.status != 'finished' or self.percentage_complete < 100
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
)
Refactor ‘finished’ to the model layer By moving it from the view we reduce the complexity of the methods in the view layer, so it’s easier to see what they do. This also renames the variable `finished` to the property `processing_finished` to disambiguate from the `job_status` field in the JSON, which can also have a value of `finished`.
2020-01-08 16:23:43 +00:00
@cached_property
def finished_processing(self):
Remove duplicative notifications_processed property It returned the same value (and had the same code as `.notifications_sent`). I think `.notifications_sent` is a better name because it’s closer to the language (‘sending’ and ‘sent’) that we use in the interface.
2020-01-16 15:40:49 +00:00
return self.notification_count == self.notifications_sent
Refactor ‘finished’ to the model layer By moving it from the view we reduce the complexity of the methods in the view layer, so it’s easier to see what they do. This also renames the variable `finished` to the property `processing_finished` to disambiguate from the `job_status` field in the JSON, which can also have a value of `finished`.
2020-01-08 16:23:43 +00:00
Use time to determine why notifications don’t exist Notifications won’t exist for a job if: - it’s just started - it started a long time ago (older than the retention period) We have a bug where: 1. Job starts processing, puts notifications on queue 2. Job finishes processing, sets status to `finished` 3. First notification gets picked up off the queue and put in the database In between 2. and 3. it’s possible for a job to be finished, but also to have no notifications. We’re saying this is because the notifications have been deleted, whereas really it’s because they haven’t been created yet. This commit fixes that bug by introducing the concept of recency for jobs. ‘Recent’ is defined as 1 day, which is: - a lot longer than it takes to create any notifications - a bit shorter than anyone’s retention time N.B. `processing_started` is defined here: https://github.com/alphagov/notifications-api/blob/879ba1d5f092dbf6e15bf9adadd53e4657660490/app/models.py#L1194 It can be `None` for scheduled jobs that haven’t started yet.
2020-01-16 16:58:26 +00:00
@property
Rename property to more accurately describe purpose `recently_created` says it would just be looking at the `created_at` field to see if it's been created recently. Technically this method isn't doing that, whilst its behaviour would be similar, it's actually different and maybe therefore a bit misleading.
2020-01-21 14:07:23 +00:00
def awaiting_processing_or_recently_processed(self):
Use time to determine why notifications don’t exist Notifications won’t exist for a job if: - it’s just started - it started a long time ago (older than the retention period) We have a bug where: 1. Job starts processing, puts notifications on queue 2. Job finishes processing, sets status to `finished` 3. First notification gets picked up off the queue and put in the database In between 2. and 3. it’s possible for a job to be finished, but also to have no notifications. We’re saying this is because the notifications have been deleted, whereas really it’s because they haven’t been created yet. This commit fixes that bug by introducing the concept of recency for jobs. ‘Recent’ is defined as 1 day, which is: - a lot longer than it takes to create any notifications - a bit shorter than anyone’s retention time N.B. `processing_started` is defined here: https://github.com/alphagov/notifications-api/blob/879ba1d5f092dbf6e15bf9adadd53e4657660490/app/models.py#L1194 It can be `None` for scheduled jobs that haven’t started yet.
2020-01-16 16:58:26 +00:00
if not self.processing_started:
# Assume that if processing hasn’t started yet then the job
# must have been created recently enough to not have any
# notifications yet
return True
Refactor to use shared date comparison function This means we don’t have to repeatedly do timezone conversions or string to datetime conversions in our business logic.
2020-09-29 13:17:12 +01:00
return is_less_than_days_ago(self.processing_started, 1)
Use time to determine why notifications don’t exist Notifications won’t exist for a job if: - it’s just started - it started a long time ago (older than the retention period) We have a bug where: 1. Job starts processing, puts notifications on queue 2. Job finishes processing, sets status to `finished` 3. First notification gets picked up off the queue and put in the database In between 2. and 3. it’s possible for a job to be finished, but also to have no notifications. We’re saying this is because the notifications have been deleted, whereas really it’s because they haven’t been created yet. This commit fixes that bug by introducing the concept of recency for jobs. ‘Recent’ is defined as 1 day, which is: - a lot longer than it takes to create any notifications - a bit shorter than anyone’s retention time N.B. `processing_started` is defined here: https://github.com/alphagov/notifications-api/blob/879ba1d5f092dbf6e15bf9adadd53e4657660490/app/models.py#L1194 It can be `None` for scheduled jobs that haven’t started yet.
2020-01-16 16:58:26 +00:00
Make a job model for individual jobs This follows the pattern of what we’ve done with services, users and events. It gives us a better interface to the data we get back from the API than dealing with the raw JSON directly. Now is a good time to do this because we’re going to be making a bunch of changes to the jobs pages, and those changes will be easier to code and understand with a sesnsible model behind them.
2020-01-08 12:23:09 +00:00
@property
def template_id(self):
return self._dict['template']
@cached_property
def template(self):
return service_api_client.get_service_template(
service_id=self.service,
template_id=self.template_id,
version=self.template_version,
)['data']
@property
def percentage_complete(self):
return self.notifications_requested / self.notification_count * 100
@property
def letter_job_can_be_cancelled(self):
if self.template['template_type'] != 'letter':
return False
if any(self.uncancellable_notifications):
return False
if not letter_can_be_cancelled(
Use utils function to parse datetime strings Rather than hard-coding a format string in a bunch of different places we can use the function we already have in utils. This commit also refactors some logic around password resets to put the date-parsing changes in the most sensible bit of the codebase, so it’s clearer what the intention of the view-layer code is.
2020-01-21 12:23:30 +00:00
'created',
utc_string_to_aware_gmt_datetime(self.created_at).replace(tzinfo=None)
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 False
return True
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
@property
def letter_printing_statement(self):
if self.upload_type != 'letter_day':
raise TypeError()
return get_letter_printing_statement(
'created',
# We have to make the time just before 5:30pm because a
# letter uploaded at 5:30pm will be printed the next day
(
utc_string_to_aware_gmt_datetime(self.created_at) - timedelta(minutes=1)
).astimezone(pytz.utc).isoformat(),
long_form=False,
)
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
@cached_property
def all_notifications(self):
return self.get_notifications(set_status_filters({}))['notifications']
@property
def uncancellable_notifications(self):
return (
n for n in self.all_notifications
if n['status'] not in CANCELLABLE_JOB_LETTER_STATUSES
)
@cached_property
def postage(self):
# There might be no notifications if the job has only just been
# created and the tasks haven't run yet
try:
return self.all_notifications[0]['postage']
except IndexError:
return self.template['postage']
@property
def letter_timings(self):
return get_letter_timings(self.created_at, postage=self.postage)
Use a ModelList for lists of jobs This follows the pattern of what we’ve done with services, users and events. It gives us a way of neatly instantiating a model for each item in the list we get back from the API and reduces the complexity of the view layer code. 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 sensible model behind them.
2020-01-08 14:29:56 +00:00
@property
def failure_rate(self):
if not self.notifications_delivered:
return 100 if self.notifications_failed else 0
return (
self.notifications_failed / (
self.notifications_failed + self.notifications_delivered
) * 100
)
@property
def high_failure_rate(self):
return self.failure_rate > 30
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_notifications(self, status):
return notification_api_client.get_notifications_for_service(
self.service, self.id, status=status,
)
def cancel(self):
if self.template_type == 'letter':
return job_api_client.cancel_letter_job(self.service, self.id)
else:
return job_api_client.cancel_job(self.service, self.id)
Use a ModelList for lists of jobs This follows the pattern of what we’ve done with services, users and events. It gives us a way of neatly instantiating a model for each item in the list we get back from the API and reduces the complexity of the view layer code. 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 sensible model behind them.
2020-01-08 14:29:56 +00:00
class ImmediateJobs(ModelList):
Rename property on ModelLists The property doesn’t represent the whole client, but just one method on it. So this commit renames the property to better describe what it is designed to store.
2020-01-16 15:57:51 +00:00
client_method = job_api_client.get_immediate_jobs
Use a ModelList for lists of jobs This follows the pattern of what we’ve done with services, users and events. It gives us a way of neatly instantiating a model for each item in the list we get back from the API and reduces the complexity of the view layer code. 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 sensible model behind them.
2020-01-08 14:29:56 +00:00
model = Job
class ScheduledJobs(ImmediateJobs):
Rename property on ModelLists The property doesn’t represent the whole client, but just one method on it. So this commit renames the property to better describe what it is designed to store.
2020-01-16 15:57:51 +00:00
client_method = job_api_client.get_scheduled_jobs
Use a ModelList for lists of jobs This follows the pattern of what we’ve done with services, users and events. It gives us a way of neatly instantiating a model for each item in the list we get back from the API and reduces the complexity of the view layer code. 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 sensible model behind them.
2020-01-08 14:29:56 +00:00
Refactor to make pagination reusable The responses we get to paginated queries from the API are fairly consistent, so we should be able to reuse the code that takes JSON from the API and turns it into Python objects. This commits factors out that code so that it is reusable (by inheriting from it).
2020-05-12 17:06:23 +01:00
class PaginatedJobs(PaginatedModelList, ImmediateJobs):
Rename property on ModelLists The property doesn’t represent the whole client, but just one method on it. So this commit renames the property to better describe what it is designed to store.
2020-01-16 15:57:51 +00:00
client_method = job_api_client.get_page_of_jobs
Show jobs on contact list It’s a bit unintuitive that starting a job from a contact list makes a copy of the file, which has no relationship to the list it was copied from. This is more of an implementation detail, rather than something that comes from people’s mental models of what is going on. Or at least that’s what I hypothesise. I think it’s clearer to show jobs that come from contact lists within the lists that they were created from. By naming the jobs by template this gives a clearer view of what messages have been sent to the group over time.
2020-05-12 17:31:01 +01:00
statuses = None
Use a ModelList for lists of jobs This follows the pattern of what we’ve done with services, users and events. It gives us a way of neatly instantiating a model for each item in the list we get back from the API and reduces the complexity of the view layer code. 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 sensible model behind them.
2020-01-08 14:29:56 +00:00
Limit jobs sent from contact list by data retention On the uploads page we only show jobs which are within a service’s data retention. This commit does the same for when we’re listing the jobs for a contact list. This matches the UI, which says a contact list has been ‘used `<count_of_jobs>` in the last <data_retention> days’
2020-12-01 13:34:31 +00:00
def __init__(self, service_id, *, contact_list_id=None, page=None, limit_days=None):
Show jobs on contact list It’s a bit unintuitive that starting a job from a contact list makes a copy of the file, which has no relationship to the list it was copied from. This is more of an implementation detail, rather than something that comes from people’s mental models of what is going on. Or at least that’s what I hypothesise. I think it’s clearer to show jobs that come from contact lists within the lists that they were created from. By naming the jobs by template this gives a clearer view of what messages have been sent to the group over time.
2020-05-12 17:31:01 +01:00
super().__init__(
service_id,
contact_list_id=contact_list_id,
statuses=self.statuses,
page=page,
Limit jobs sent from contact list by data retention On the uploads page we only show jobs which are within a service’s data retention. This commit does the same for when we’re listing the jobs for a contact list. This matches the UI, which says a contact list has been ‘used `<count_of_jobs>` in the last <data_retention> days’
2020-12-01 13:34:31 +00:00
limit_days=limit_days,
Show jobs on contact list It’s a bit unintuitive that starting a job from a contact list makes a copy of the file, which has no relationship to the list it was copied from. This is more of an implementation detail, rather than something that comes from people’s mental models of what is going on. Or at least that’s what I hypothesise. I think it’s clearer to show jobs that come from contact lists within the lists that they were created from. By naming the jobs by template this gives a clearer view of what messages have been sent to the group over time.
2020-05-12 17:31:01 +01:00
)
class PaginatedJobsAndScheduledJobs(PaginatedJobs):
statuses = job_api_client.NON_CANCELLED_JOB_STATUSES
Use a ModelList for lists of jobs This follows the pattern of what we’ve done with services, users and events. It gives us a way of neatly instantiating a model for each item in the list we get back from the API and reduces the complexity of the view layer code. 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 sensible model behind them.
2020-01-08 14:29:56 +00:00
Refactor to make pagination reusable The responses we get to paginated queries from the API are fairly consistent, so we should be able to reuse the code that takes JSON from the API and turns it into Python objects. This commits factors out that code so that it is reusable (by inheriting from it).
2020-05-12 17:06:23 +01:00
class PaginatedUploads(PaginatedModelList, ImmediateJobs):
Rename property on ModelLists The property doesn’t represent the whole client, but just one method on it. So this commit renames the property to better describe what it is designed to store.
2020-01-16 15:57:51 +00:00
client_method = job_api_client.get_uploads
Reference in New Issue Copy Permalink