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.
Update notifications/sms|email endpoint to send the template version to the queue.
Update the process_job celery talk to send the template version to the queue.
When the send_sms|send_email task runs it will get the template by id and version.
Created a data migration script to add the template_vesion column for jobs and notifications.
The existing jobs and notifications are given the template_version of the current template.
There is a chance this is the wrong template version, but deemed okay since the application is not live.
Create unit test for the dao_get_template_versions method.
Rename /template/<id>/version to /template/<id>/versions which returns all versions for that template id and service id.
Templates are created in the admin app and persisted in the API.
They are consumed:
- in the admin app, by requesting them from the API
- in the API, by loading them from the database
There are two potential places where unescaped HTML could be sent to a user:
- when the admin app is previewing a template (it has to render the template as
markup in order to show the placeholders)
- in the body of an email
For all consumers to have confidence that the templates are safe, it makes sense
to santitise them at the point of creation (and modification). This also avoids
any performance issues that could come from doing it at the point of requesting
a template.
In the future they could be created by a direct API call, bypassing the admin
app. Therefore it makes sense for the API to sanitise them.
The commit sanitises templates using a Mozilla’s Bleach library[1]. It is
configured to get the text content of the template, minus any HTML tags. It is
not using a regex because[2].
1. https://github.com/mozilla/bleach
2. http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454
