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.
10 seconds, 1 minute, 5 minutes, 1 hour and 4 hours.
Total elapsed wait is max 5 hours 6 minutes and 10 seconds.
Changed visibility window of SQS to be 4 hours 10 seconds, longer the max retry period.
Before:
```json
{'data': {'template': '…'}}
```
There’s no need to wrap the response in key because there will only
ever be one valid key for the template preview endpoint.
Flatter is better:
```json
{
'content': '…',
'subject': '…',
'template_type': '…',
…
}
```
The response will be different if there’s an error, but you should be
checking the status code first anyway.
This commit:
- changes the template preview endpoint to return the above format
- adds a test to make sure that the original `/service/…/template/…`
endpoint still returns JSON in the same format (with a `data` key)
There’s a need for users of the API to be able to take advantage of
Notify’s template rendering.
For example, there’s a service that’s building a case management system.
Their users are sending emails on a case-by-case basis. Before they
send an email, it’s ressuring to double check that the right data is
being inserted, that the right template is being used, etc.
This commit:
- adds a separate endpoint for previewing a template, with
personalisation taken from the get parameters of the request
- beefs up the tests around getting a template
Not part of this pull request:
- making this enpoint publicly accessible
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.
It’s going to be useful to see all the notifications for a job that are
failed/delivered/etc.
The API seems to support this behaviour already, but it doesn’t seem to
be tested.
This commit adds some testsfor the DAO and REST layers.
dao was deleting all permissions for that user (regardless of service
id) as the last filter on the permissions dao get_query method won.
I've added a replace flag to the set_user_service_permission method
so that it can handle adding new users + permissions and editing
of existing users' permissions.
Also by pass the get_query method until it can be refactored to work
correctly.
For now execute the filter query directly on the model.
