notifications, when retrieved by notification id, or service id (i.e.
all notifications for service).
There is a new element returned at top level of notification json called
body, which is the template content merged with personalisation. This
is consistent with api to endpoint to create notification which returns
what was sent as 'body' in json response.
Merging of template with personalisation is done in the
NotificationStatusSchema.
Personalisation data in encrypted before storing in db.
or param errors to raise invalid data exception. That will cause
those responses to be handled in by errors.py, which will log
the errors.
Set most of schemas to strict mode so that marshmallow will raise
exception rather than checking for errors in return tuple from load.
Added handler to errors.py for marshmallow validation errors.
was being lazily loaded to get notification ids, so every time a job is loaded it would potentially select thousands of notifications from the database
It is also discovered that columns that have a default value and use the version mixin must set the value when creating the db object before the insert otherwise the history table will be missing the default value.
Updated the templates_history.created_by_id with a value where missing, using the current version of the template for this value.
Update templates_history.archived to false. This is okay as we do not yet have a way to set this value to true.
Removed the versions attribute from the TemplateSchema, there is not a need for this column.
Removed the validation in the schema - it was adding complexity, let the unique constraint on the db throw the exception. This should only ever happen on a race condition which seems unlikely (two people changing a service to the same name at the same time)
Do no set debug=true to the test config. If debug=true it changes the behaviour of the error handlers, throwing the exception rather than returning a 500.
This uses the `format_phone_number` method from utils to output phone numbers
in a consistent format. It is added to the schemas, so will be applied before
the API tries to do anything with a provided phone number.
So now the API will accept any of the following:
- 07123456789
- 07123 456789
- 07123-456-789
- 00447123456789
- 00 44 7123456789
- +447123456789
- +44 7123 456 789
- +44 (0)7123 456 789
…but the API will always hand off phone numbers to 3rd party APIs in the format
- +447123456789
The test for this is slightly convoluted, because template IDs are still
database IDs, and can’t consistently be mocked, therefore we have to ignore that
part of the call to `encrypt()`.
