moved api_key secret manipulation (generating and getting) into
authentiation/utils, and added a property on the model, to facilitate
easier matching of authenticated requests and the api keys they used
moved from notifications/rest -> service/rest and job/rest respectively
endpoint routes not affected
removed requires_admin decorator - that should be set by nginx config
as opposed to python code
It seems like an oversight not to include the notification type in the notifcation.
When updating statistics a query to the template table is required to get the type, this update will mean that query does not have to happen.
If the notification ends up in the retry queue and the delivery app is restarted the notification will get sent twice.
This is because when the app is restarted another message will be in the retry queue as message available which is a
duplicate of the one in the queue that is a message in flight.
This should complete https://www.pivotaltracker.com/story/show/121844427
* single-column static data table that currently contains two types: 'normal' and 'team'
* key_type foreign-keyed from api_keys
- must be not null
- existing rows set to 'normal'
* key_type foreign-keyed from notifications
- nullable
- existing rows set to null
* api_key foreign-keyed from notifications
- nullable
- existing rows set to null
The only update we should be doing to an api key is to expire/revoke the api key.
Removed the update_dict from the the save method.
Added an expire_api_key method that only updates the api key with an expiry date.
We were dropping all tables at the end of the test run, however the alembic_version table is not part of the metadata so was being persisted. Alembic then doesn't upgrade the database next test run, since the version appears up to date, so we were, in the notify_db_session fixture, recreating from MetaData (sqlalchemy models). This involves quite a costly comparison of the postgres system tables and the tables in models.py, which was adding half a second to each test that uses the notify_db_session fixture (virtually all of them).
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)
