Added the GET /<uuid:service_id>/letter-contact/<uuid:letter_contact_id>
endpoint for returning a letter contact for a service with the letter contact id
Added the DAO for returning a letter contact by id
Added the GET '/<uuid:service_id>/letter-contact' endpoint for returning
all letter contact blocks for a service.
Updated the DAO for service letter contacts to return the default letter
contact first.
Removed the tests for trial mode service for the scheduled tasks and the process job.
Having the validation in the POST notification and create job endpoint is enough.
Updated the test_service_whitelist test because the order of the array is not gaurenteed.
On the frontend, we’re letting users register with international phone
numbers. So we shouldn’t block users from doing this on the API side.
Same thing for the whitelist, where we’re also allowing international
phone numbers now.
1. For both email and sms, store [] in monthly_totals if
there is no billing data (no notifications sent etc.) and
return this via the API
2. General refactoring of indentation
Why is this needed?
When a user updates a service name they enter the new name in a form, are then asked to confirm the change by entering their password. Then the API call to update_service is called. If we let the update serivce API call fail with the integrity constraint it will be ackward for the user.
So that when the admin gets notifications, the template they return
also has a "redact_personalisation" boolean attached to it. Note, it
won't do the redacting on the api - that'll be part of the admin.
Under the hood, this uses an association_proxy, which is essentially
black magic. But it proxies the `redact_personalisation` property of
`TemplateRedacted` onto the `Template` object, so that Marshmallow
can pick it up.
Note: NOT currently added to NotificationWithTemplateHistory
* Alter config so an error will be raised if you forget to mock out a
celery call in one of your tests
* Remove an unneeded exception type that was masking errors
currently, they're made by creating a one-line job, but we want to
reduce task/csv file noise so we're moving them to persist in the
same vein as API usage. However, we can't just call through to that
since there are some differences:
* no api keys
* tighter control over API format
* no scheduling
* no client references
etc.
So, re-using as much of the v2 validation stuff as possible, I've
created this file that just does basic validation, and then calls
through to persist_notification and schedules a task. Woo.
