darkhelm/notifications-api
1
0
Fork 0
mirror of https://github.com/GSA/notifications-api.git synced 2025-12-22 08:21:13 -05:00
Code Issues Packages Projects Releases Wiki Activity
Files
321b4913eddd1a213539aad3d268f0856fd49402
notifications-api/tests/app/dao/test_uploads_dao.py

369 lines
14 KiB
Python
Raw Normal View History

Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
from datetime import datetime, timedelta
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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
from freezegun import freeze_time
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
And an endpoint to get uploaded letters for a day Because we won’t be showing uploaded letters individually on the uploads page any more we need a way of listing them. This should be by printing day, to match how we’re grouping them on the uploads page. The response matches a normal `get_notifications` response so we can reuse the same code in the admin app.
2020-05-11 10:51:40 +01:00
from app.dao.uploads_dao import dao_get_uploads_by_service_id, dao_get_uploaded_letters_by_print_date
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
from app.models import LETTER_TYPE, JOB_STATUS_IN_PROGRESS
Don’t return jobs sent from contact lists Now that we’re grouping jobs sent from contact lists within their parent, they shouldn’t also be listed on the jobs page at the top level. The jobs page uses the uploads API, not the jobs API, so this commit makes sure that filtering is happening in the proper place.
2020-12-01 15:23:38 +00:00
from tests.app.db import (
create_job,
create_service,
create_service_data_retention,
create_service_contact_list,
create_template,
create_notification,
)
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
def create_uploaded_letter(letter_template, service, status='created', created_at=None):
return create_notification(
template=letter_template,
to_field="file-name",
status=status,
reference="dvla-reference",
client_reference="file-name",
one_off=True,
created_by_id=service.users[0].id,
created_at=created_at
)
Add `type=int` to `request.args.get`, if the arg is an int it's returned else None. This means we ignore the arg if its the wrong data type and we don't need to handle the error.
2019-12-06 13:10:38 +00:00
def create_uploaded_template(service):
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
return create_template(
service,
template_type=LETTER_TYPE,
template_name='Pre-compiled PDF',
subject='Pre-compiled PDF',
content="",
hidden=True,
postage="second",
)
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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
@freeze_time("2020-02-02 14:00") # GMT time
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
def test_get_uploads_for_service(sample_template):
Finding only jobs and letters within data retention works and tested
2020-03-10 10:33:30 +00:00
create_service_data_retention(sample_template.service, 'sms', days_of_retention=9)
Don’t return jobs sent from contact lists Now that we’re grouping jobs sent from contact lists within their parent, they shouldn’t also be listed on the jobs page at the top level. The jobs page uses the uploads API, not the jobs API, so this commit makes sure that filtering is happening in the proper place.
2020-12-01 15:23:38 +00:00
contact_list = create_service_contact_list()
# Jobs created from contact lists should be filtered out
create_job(sample_template, contact_list_id=contact_list.id)
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
job = create_job(sample_template, processing_started=datetime.utcnow())
Add `type=int` to `request.args.get`, if the arg is an int it's returned else None. This means we ignore the arg if its the wrong data type and we don't need to handle the error.
2019-12-06 13:10:38 +00:00
letter_template = create_uploaded_template(sample_template.service)
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
letter = create_uploaded_letter(letter_template, sample_template.service)
other_service = create_service(service_name="other service")
other_template = create_template(service=other_service)
other_job = create_job(other_template, processing_started=datetime.utcnow())
Add `type=int` to `request.args.get`, if the arg is an int it's returned else None. This means we ignore the arg if its the wrong data type and we don't need to handle the error.
2019-12-06 13:10:38 +00:00
other_letter_template = create_uploaded_template(other_service)
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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
create_uploaded_letter(other_letter_template, other_service)
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
uploads_from_db = dao_get_uploads_by_service_id(job.service_id).items
other_uploads_from_db = dao_get_uploads_by_service_id(other_job.service_id).items
assert len(uploads_from_db) == 2
Return template type in uploads response We need template type for the uploads response, which will eventually supercede the jobs response. At the moment the page uses both.
2020-02-25 17:13:01 +00:00
assert uploads_from_db[0] == (
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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
None,
'Uploaded letters',
Return template type in uploads response We need template type for the uploads response, which will eventually supercede the jobs response. At the moment the page uses both.
2020-02-25 17:13:01 +00:00
1,
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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
'letter',
None,
letter.created_at.replace(hour=17, minute=30, second=0, microsecond=0),
None,
letter.created_at.replace(hour=17, minute=30, second=0, microsecond=0),
Return template type in uploads response We need template type for the uploads response, which will eventually supercede the jobs response. At the moment the page uses both.
2020-02-25 17:13:01 +00:00
None,
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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
'letter_day',
Return template type in uploads response We need template type for the uploads response, which will eventually supercede the jobs response. At the moment the page uses both.
2020-02-25 17:13:01 +00:00
None,
)
assert uploads_from_db[1] == (
job.id,
job.original_file_name,
job.notification_count,
'sms',
Finding only jobs and letters within data retention works and tested
2020-03-10 10:33:30 +00:00
9,
Return template type in uploads response We need template type for the uploads response, which will eventually supercede the jobs response. At the moment the page uses both.
2020-02-25 17:13:01 +00:00
job.created_at,
job.scheduled_for,
job.processing_started,
job.job_status,
"job",
Return recipient for letter uploads If your caseworking system always spits out files with the same name it will be hard to differentiate them when looking at the uploads page. Seeing who the letter was sent to will help you differentiate them. We can’t do this until the API returns the recipient.
2020-02-27 13:19:51 +00:00
None,
Return template type in uploads response We need template type for the uploads response, which will eventually supercede the jobs response. At the moment the page uses both.
2020-02-25 17:13:01 +00:00
)
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
assert len(other_uploads_from_db) == 2
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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
assert other_uploads_from_db[0] == (
None,
'Uploaded letters',
1,
'letter',
None,
letter.created_at.replace(hour=17, minute=30, second=0, microsecond=0),
None,
letter.created_at.replace(hour=17, minute=30, second=0, microsecond=0),
None,
"letter_day",
None,
)
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
assert other_uploads_from_db[1] == (other_job.id,
other_job.original_file_name,
other_job.notification_count,
Return template type in uploads response We need template type for the uploads response, which will eventually supercede the jobs response. At the moment the page uses both.
2020-02-25 17:13:01 +00:00
other_job.template.template_type,
Finding only jobs and letters within data retention works and tested
2020-03-10 10:33:30 +00:00
7,
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
other_job.created_at,
other_job.scheduled_for,
other_job.processing_started,
Return recipient for letter uploads If your caseworking system always spits out files with the same name it will be hard to differentiate them when looking at the uploads page. Seeing who the letter was sent to will help you differentiate them. We can’t do this until the API returns the recipient.
2020-02-27 13:19:51 +00:00
other_job.job_status,
"job",
None)
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
assert uploads_from_db[1] != other_uploads_from_db[1]
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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
@freeze_time("2020-02-02 18:00")
def test_get_uploads_for_service_groups_letters(sample_template):
letter_template = create_uploaded_template(sample_template.service)
# Just gets into yesterday’s print run
create_uploaded_letter(letter_template, sample_template.service, created_at=(
datetime(2020, 2, 1, 17, 29, 59)
))
# Yesterday but in today’s print run
create_uploaded_letter(letter_template, sample_template.service, created_at=(
datetime(2020, 2, 1, 17, 30)
))
# First thing today
create_uploaded_letter(letter_template, sample_template.service, created_at=(
datetime(2020, 2, 2, 0, 0)
))
# Just before today’s print deadline
create_uploaded_letter(letter_template, sample_template.service, created_at=(
datetime(2020, 2, 2, 17, 29, 59)
))
# Just missed today’s print deadline
create_uploaded_letter(letter_template, sample_template.service, created_at=(
datetime(2020, 2, 2, 17, 30)
))
uploads_from_db = dao_get_uploads_by_service_id(sample_template.service_id).items
assert [
(upload.notification_count, upload.created_at)
for upload in uploads_from_db
] == [
(1, datetime(2020, 2, 3, 17, 30)),
(3, datetime(2020, 2, 2, 17, 30)),
(1, datetime(2020, 2, 1, 17, 30)),
]
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
def test_get_uploads_does_not_return_cancelled_jobs_or_letters(sample_template):
create_job(sample_template, job_status='scheduled')
create_job(sample_template, job_status='cancelled')
Add `type=int` to `request.args.get`, if the arg is an int it's returned else None. This means we ignore the arg if its the wrong data type and we don't need to handle the error.
2019-12-06 13:10:38 +00:00
letter_template = create_uploaded_template(sample_template.service)
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
create_uploaded_letter(letter_template, sample_template.service, status='cancelled')
assert len(dao_get_uploads_by_service_id(sample_template.service_id).items) == 0
def test_get_uploads_orders_by_created_at_desc(sample_template):
Add `type=int` to `request.args.get`, if the arg is an int it's returned else None. This means we ignore the arg if its the wrong data type and we don't need to handle the error.
2019-12-06 13:10:38 +00:00
letter_template = create_uploaded_template(sample_template.service)
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
upload_1 = create_job(sample_template, processing_started=datetime.utcnow(),
job_status=JOB_STATUS_IN_PROGRESS)
upload_2 = create_job(sample_template, processing_started=datetime.utcnow(),
job_status=JOB_STATUS_IN_PROGRESS)
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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
create_uploaded_letter(letter_template, sample_template.service, status='delivered')
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
results = dao_get_uploads_by_service_id(service_id=sample_template.service_id).items
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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
assert [
(result.id, result.upload_type) for result in results
] == [
(None, 'letter_day'),
(upload_2.id, 'job'),
(upload_1.id, 'job'),
]
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
def test_get_uploads_orders_by_processing_started_desc(sample_template):
days_ago = datetime.utcnow() - timedelta(days=3)
upload_1 = create_job(sample_template, processing_started=datetime.utcnow() - timedelta(days=1),
created_at=days_ago,
job_status=JOB_STATUS_IN_PROGRESS)
upload_2 = create_job(sample_template, processing_started=datetime.utcnow() - timedelta(days=2),
created_at=days_ago,
job_status=JOB_STATUS_IN_PROGRESS)
results = dao_get_uploads_by_service_id(service_id=sample_template.service_id).items
assert len(results) == 2
assert results[0].id == upload_1.id
assert results[1].id == upload_2.id
There seems to be a UTC time bug around the dao_get_uploads_by_service_id function. To fix the build tonight I'm putting freezing the time for the test. But will investigate further tomorrow.
2020-10-27 17:25:58 +00:00
@freeze_time("2020-10-27 16:15") # GMT time
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
def test_get_uploads_orders_by_processing_started_and_created_at_desc(sample_template):
Add `type=int` to `request.args.get`, if the arg is an int it's returned else None. This means we ignore the arg if its the wrong data type and we don't need to handle the error.
2019-12-06 13:10:38 +00:00
letter_template = create_uploaded_template(sample_template.service)
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
days_ago = datetime.utcnow() - timedelta(days=4)
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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
create_uploaded_letter(letter_template, service=letter_template.service)
Add `type=int` to `request.args.get`, if the arg is an int it's returned else None. This means we ignore the arg if its the wrong data type and we don't need to handle the error.
2019-12-06 13:10:38 +00:00
upload_2 = create_job(sample_template, processing_started=datetime.utcnow() - timedelta(days=1),
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
created_at=days_ago,
job_status=JOB_STATUS_IN_PROGRESS)
Add `type=int` to `request.args.get`, if the arg is an int it's returned else None. This means we ignore the arg if its the wrong data type and we don't need to handle the error.
2019-12-06 13:10:38 +00:00
upload_3 = create_job(sample_template, processing_started=datetime.utcnow() - timedelta(days=2),
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
created_at=days_ago,
job_status=JOB_STATUS_IN_PROGRESS)
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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
create_uploaded_letter(letter_template, service=letter_template.service,
created_at=datetime.utcnow() - timedelta(days=3))
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
results = dao_get_uploads_by_service_id(service_id=sample_template.service_id).items
assert len(results) == 4
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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
assert results[0].id is None
Add `type=int` to `request.args.get`, if the arg is an int it's returned else None. This means we ignore the arg if its the wrong data type and we don't need to handle the error.
2019-12-06 13:10:38 +00:00
assert results[1].id == upload_2.id
assert results[2].id == upload_3.id
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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
assert results[3].id is None
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
@freeze_time('2020-04-02 14:00') # Few days after the clocks go forward
Finding only jobs and letters within data retention works and tested
2020-03-10 10:33:30 +00:00
def test_get_uploads_only_gets_uploads_within_service_retention_period(sample_template):
letter_template = create_uploaded_template(sample_template.service)
create_service_data_retention(sample_template.service, 'sms', days_of_retention=3)
days_ago = datetime.utcnow() - timedelta(days=4)
upload_1 = create_uploaded_letter(letter_template, service=letter_template.service)
upload_2 = create_job(
sample_template, processing_started=datetime.utcnow() - timedelta(days=1), created_at=days_ago,
job_status=JOB_STATUS_IN_PROGRESS
)
# older than custom retention for sms:
create_job(
sample_template, processing_started=datetime.utcnow() - timedelta(days=5), created_at=days_ago,
job_status=JOB_STATUS_IN_PROGRESS
)
upload_3 = create_uploaded_letter(
letter_template, service=letter_template.service, created_at=datetime.utcnow() - timedelta(days=3)
)
# older than retention for sms but within letter retention:
upload_4 = create_uploaded_letter(
letter_template, service=letter_template.service, created_at=datetime.utcnow() - timedelta(days=6)
)
# older than default retention for letters:
create_uploaded_letter(
letter_template, service=letter_template.service, created_at=datetime.utcnow() - timedelta(days=8)
)
results = dao_get_uploads_by_service_id(service_id=sample_template.service_id).items
assert len(results) == 4
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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
# Uploaded letters get their `created_at` shifted time of printing
# 17:30 BST == 16:30 UTC
assert results[0].created_at == upload_1.created_at.replace(hour=16, minute=30, second=0, microsecond=0)
# Jobs keep their original `created_at`
assert results[1].created_at == upload_2.created_at.replace(hour=14, minute=00, second=0, microsecond=0)
Finding only jobs and letters within data retention works and tested
2020-03-10 10:33:30 +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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
# Still in BST here…
assert results[2].created_at == upload_3.created_at.replace(hour=16, minute=30, second=0, microsecond=0)
# Now we’ve gone far enough back to be in GMT
# 17:30 GMT == 17:30 UTC
assert results[3].created_at == upload_4.created_at.replace(hour=17, minute=30, second=0, microsecond=0)
@freeze_time('2020-02-02 14:00')
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
def test_get_uploads_is_paginated(sample_template):
Add `type=int` to `request.args.get`, if the arg is an int it's returned else None. This means we ignore the arg if its the wrong data type and we don't need to handle the error.
2019-12-06 13:10:38 +00:00
letter_template = create_uploaded_template(sample_template.service)
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
create_uploaded_letter(
letter_template, sample_template.service, status='delivered',
created_at=datetime.utcnow() - timedelta(minutes=3),
)
create_job(
sample_template, processing_started=datetime.utcnow() - timedelta(minutes=2),
job_status=JOB_STATUS_IN_PROGRESS,
)
create_uploaded_letter(
letter_template, sample_template.service, status='delivered',
created_at=datetime.utcnow() - timedelta(minutes=1),
)
create_job(
sample_template, processing_started=datetime.utcnow(),
job_status=JOB_STATUS_IN_PROGRESS,
)
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
results = dao_get_uploads_by_service_id(sample_template.service_id, page=1, page_size=1)
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
assert results.per_page == 1
assert results.total == 3
assert len(results.items) == 1
assert results.items[0].created_at == datetime.utcnow().replace(hour=17, minute=30, second=0, microsecond=0)
assert results.items[0].notification_count == 2
assert results.items[0].upload_type == 'letter_day'
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
results = dao_get_uploads_by_service_id(sample_template.service_id, page=2, page_size=1)
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +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 this commit starts grouping together uploaded letters. It does this 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. The code for this is a bit gnarly because: - timezones - the print cutoff doesn’t align with the end of a day - we have to do this in SQL because it wouldn’t be efficient to query thousands of letters and then do the timezone calculations on them in Python
2020-05-11 10:51:33 +01:00
assert len(results.items) == 1
assert results.items[0].created_at == datetime.utcnow().replace(hour=14, minute=0, second=0, microsecond=0)
assert results.items[0].notification_count == 1
assert results.items[0].upload_type == 'job'
Add uploads blueprint, the endpoint returns a combination of uploaded letters and jobs. The endpoint returns data about the uploaded letter or job, including notification statistics for the upload. The data is ordered by scheduled for and created_at. It is likely this endppoint will need additional data for the UI to display, for the first iteration this will enable the /uploads page to show both letters and jobs. Only letter uploaded by the UI are included in the resultset. Add file name to resultset.
2019-12-03 15:53:32 +00:00
def test_get_uploads_returns_empty_list(sample_service):
items = dao_get_uploads_by_service_id(sample_service.id).items
assert items == []
And an endpoint to get uploaded letters for a day Because we won’t be showing uploaded letters individually on the uploads page any more we need a way of listing them. This should be by printing day, to match how we’re grouping them on the uploads page. The response matches a normal `get_notifications` response so we can reuse the same code in the admin app.
2020-05-11 10:51:40 +01:00
@freeze_time('2020-02-02 14:00')
def test_get_uploaded_letters_by_print_date(sample_template):
letter_template = create_uploaded_template(sample_template.service)
# Letters for the previous day’s run
Do extra code style checks with flake8-bugbear Flake8 Bugbear checks for some extra things that aren’t code style errors, but are likely to introduce bugs or unexpected behaviour. A good example is having mutable default function arguments, which get shared between every call to the function and therefore mutating a value in one place can unexpectedly cause it to change in another. This commit enables all the extra warnings provided by Flake8 Bugbear, except for: - the line length one (because we already lint for that separately) - B903 Data class should either be immutable or use `__slots__` because this seems to false-positive on some of our custom exceptions - B902 Invalid first argument 'cls' used for instance method because some SQLAlchemy decorators (eg `declared_attr`) make things that aren’t formally class methods take a class not an instance as their first argument It disables: - _B306: BaseException.message is removed in Python 3_ because I think our exceptions have a custom structure that means the `.message` attribute is still present Matches the work done in other repos: - https://github.com/alphagov/notifications-admin/pull/3172/files
2020-12-22 15:46:31 +00:00
for _ in range(3):
And an endpoint to get uploaded letters for a day Because we won’t be showing uploaded letters individually on the uploads page any more we need a way of listing them. This should be by printing day, to match how we’re grouping them on the uploads page. The response matches a normal `get_notifications` response so we can reuse the same code in the admin app.
2020-05-11 10:51:40 +01:00
create_uploaded_letter(
letter_template, sample_template.service, status='delivered',
created_at=datetime.utcnow().replace(day=1, hour=17, minute=29, second=59)
)
# Letters from yesterday that rolled into today’s run
Do extra code style checks with flake8-bugbear Flake8 Bugbear checks for some extra things that aren’t code style errors, but are likely to introduce bugs or unexpected behaviour. A good example is having mutable default function arguments, which get shared between every call to the function and therefore mutating a value in one place can unexpectedly cause it to change in another. This commit enables all the extra warnings provided by Flake8 Bugbear, except for: - the line length one (because we already lint for that separately) - B903 Data class should either be immutable or use `__slots__` because this seems to false-positive on some of our custom exceptions - B902 Invalid first argument 'cls' used for instance method because some SQLAlchemy decorators (eg `declared_attr`) make things that aren’t formally class methods take a class not an instance as their first argument It disables: - _B306: BaseException.message is removed in Python 3_ because I think our exceptions have a custom structure that means the `.message` attribute is still present Matches the work done in other repos: - https://github.com/alphagov/notifications-admin/pull/3172/files
2020-12-22 15:46:31 +00:00
for _ in range(30):
And an endpoint to get uploaded letters for a day Because we won’t be showing uploaded letters individually on the uploads page any more we need a way of listing them. This should be by printing day, to match how we’re grouping them on the uploads page. The response matches a normal `get_notifications` response so we can reuse the same code in the admin app.
2020-05-11 10:51:40 +01:00
create_uploaded_letter(
letter_template, sample_template.service, status='delivered',
created_at=datetime.utcnow().replace(day=1, hour=17, minute=30, second=0)
)
# Letters that just made today’s run
Do extra code style checks with flake8-bugbear Flake8 Bugbear checks for some extra things that aren’t code style errors, but are likely to introduce bugs or unexpected behaviour. A good example is having mutable default function arguments, which get shared between every call to the function and therefore mutating a value in one place can unexpectedly cause it to change in another. This commit enables all the extra warnings provided by Flake8 Bugbear, except for: - the line length one (because we already lint for that separately) - B903 Data class should either be immutable or use `__slots__` because this seems to false-positive on some of our custom exceptions - B902 Invalid first argument 'cls' used for instance method because some SQLAlchemy decorators (eg `declared_attr`) make things that aren’t formally class methods take a class not an instance as their first argument It disables: - _B306: BaseException.message is removed in Python 3_ because I think our exceptions have a custom structure that means the `.message` attribute is still present Matches the work done in other repos: - https://github.com/alphagov/notifications-admin/pull/3172/files
2020-12-22 15:46:31 +00:00
for _ in range(30):
And an endpoint to get uploaded letters for a day Because we won’t be showing uploaded letters individually on the uploads page any more we need a way of listing them. This should be by printing day, to match how we’re grouping them on the uploads page. The response matches a normal `get_notifications` response so we can reuse the same code in the admin app.
2020-05-11 10:51:40 +01:00
create_uploaded_letter(
letter_template, sample_template.service, status='delivered',
created_at=datetime.utcnow().replace(hour=17, minute=29, second=59)
)
# Letters that just missed today’s run
Do extra code style checks with flake8-bugbear Flake8 Bugbear checks for some extra things that aren’t code style errors, but are likely to introduce bugs or unexpected behaviour. A good example is having mutable default function arguments, which get shared between every call to the function and therefore mutating a value in one place can unexpectedly cause it to change in another. This commit enables all the extra warnings provided by Flake8 Bugbear, except for: - the line length one (because we already lint for that separately) - B903 Data class should either be immutable or use `__slots__` because this seems to false-positive on some of our custom exceptions - B902 Invalid first argument 'cls' used for instance method because some SQLAlchemy decorators (eg `declared_attr`) make things that aren’t formally class methods take a class not an instance as their first argument It disables: - _B306: BaseException.message is removed in Python 3_ because I think our exceptions have a custom structure that means the `.message` attribute is still present Matches the work done in other repos: - https://github.com/alphagov/notifications-admin/pull/3172/files
2020-12-22 15:46:31 +00:00
for _ in range(3):
And an endpoint to get uploaded letters for a day Because we won’t be showing uploaded letters individually on the uploads page any more we need a way of listing them. This should be by printing day, to match how we’re grouping them on the uploads page. The response matches a normal `get_notifications` response so we can reuse the same code in the admin app.
2020-05-11 10:51:40 +01:00
create_uploaded_letter(
letter_template, sample_template.service, status='delivered',
created_at=datetime.utcnow().replace(hour=17, minute=30, second=0)
)
result = dao_get_uploaded_letters_by_print_date(
sample_template.service_id,
datetime.utcnow(),
)
assert result.total == 60
assert len(result.items) == 50
assert result.has_next is True
assert result.has_prev is False
result = dao_get_uploaded_letters_by_print_date(
sample_template.service_id,
datetime.utcnow(),
page=10,
page_size=2,
)
assert result.total == 60
assert len(result.items) == 2
assert result.has_next is True
assert result.has_prev is True
Reference in New Issue Copy Permalink