The response files we receive from the DVLA when we send letters
contain a row for each letter and a field with a value of 'Unsorted' or
'Sorted'. This table will be used to store the total number of
'Unsorted' and 'Sorted' letter notifications per day.
* Rather than an abort 404 returned a 500 and InvalidRequest so that the
error is more easily handled on the admin console. If the file is
missing but expected to be there is actually an internal error for admin
* Refactored the code to remove duplicate code in calls to template
preview by creating a new private method which is called with specific
parameters
* Added is_precompiled_letter method to letter/utils.py
* Added tests for letter/utils.py
* Added tests for the rest endpoint
* Moved the Precompiled name to a central location
* Added hidden field to the test method to create a template
This will continue to update the notification history for letter notifications.
We currently have an issue where the responses to letters from the provider is taking a long time.
This is due to the manual nature of their process.
Updating the status of the letter will still work if the notification has been purged.
Also turned back on the purge letter notification scheduled task.
* Added missing items from template which are required
* Returned the file as a JSON string with the file as a base64 encoded
string
* Updated tests to match teh desired format
Is will allow the admin application to call into the api instead of
making the call itself. This will allow the api to make decision for
precompiled pdf without having to update the admin app.
- Added new endpoint
- Added tests for the endpoint
Since we send all one off messages as priority
[now](https://github.com/alphagov/notifications-api/pull/1722), we don’t
need to explicitly mark the ‘Example text message template’ template as
being priority.
This commit retroactively removes the priority flag from these
templates, so that they can’t be reused to send other messages as
priority. I don’t think this is a real problem now, but worth cleaning
this up.
This query will hit approximately 827 templates.
We were already counting the billable units in PDFs that we generate.
We are now also counting the number of billable units in pre-compiled letters
and saving the result.
The vast majority of messages that are being sent one-off are
time-sensitive. A typical example is a caseworker on the phone who sends
a message at the end of the call. They normally wait until the message
has been delivered, so all the time they’re waiting is time when they
can’t be helping someone else.
What we don’t want to happen is for the messages they’re sending to get
stuck behind a big lump of GOV.UK Subscription emails or passport
reminder texts. I think the best way to do this is shift them onto the
priority queue.
We’re currently seeing queue sizes of up to 5,000 on the ‘normal’
queues; I don’t think there’s any risk of this change making the
priority queue more heavily-laden than this. Especially since the
traffic patterns of users sending one-off messages won’t be spiky.
- was getting KeyError: 'Error' test failures due to the side_effect not generating enough information to be used in the ClientError class, this PR adds missing information.
Postcodes are required for created letters, but not for precompiled, this fix allows postcodes to be None in the model.
As postcodes are still required for created letter they should be caught by validation schemas in the POST handler
