It’s nicer to have emails with a sender name, as well as the raw email
address.
Amazon SES can acheive this by using the format
```
"Sender name" <sender.name@domain.com>
```
— http://docs.aws.amazon.com/ses/latest/DeveloperGuide/email-format.html
We also have to remove all non-ASCII characters from the sender name,
because SMTP only supports 7-bit ASCII:
> A field name MUST be composed of printable US-ASCII characters (i.e.,
> characters that have values between 33 and 126, inclusive), except
> colon.
— http://www.ietf.org/rfc/rfc5322.txt
We use the service name as the sender name when:
- sending emails from the API
- sending emails from a CSV file
We use GOV.UK Notify as the sender name when:
- sending invitation emails
- sending password reset emails
This means we will retain notifications for a full week and not
delete records that are 7 x 24 hours older than the time of the run of
the deletion task.
Also the task only needs to run once a day now, so I have changed
the celery config for the deletion tasks.
revoking an api key the service it associated with was of course added
to db.session.dirty.
That resulted in an updated version of service being added to the
service history table that showed no visible difference from that
record immediately precending it as the change was to another table,
namely the api_key table. A new api key or revoked api key was correctly
added to api_key and api_key_history tables. However I think an
'unchanged' service history record may be a bit confusing as you'd need
to correlate with api_keys to work out what the change was.
I think it's best to just record the new/revoked api_key and not create
another version of the service.
This pr wraps the exisiting versioned decorator with one that take a
class which you are interested in versioning.
Using the new decorator you only get a new version and history record
for the class you pass to outer decorator.
If the exising behaviour is acceptable to the powers that be then by all
means ignore/close this pr.
Status codes from mmg are:
2: UNDELIVERABLE Message is undeliverable.
3: DELIVERED Message is delivered.
4: EXPIRED Message is expired.
5: REJECTED Message is rejected.
The response import was missing, which broke things.
There was no test to catch this.
This commit adds a rudimentary test to make sure that the endpoint
doesn’t 500, at the very least.
adapted to recording inserts and updates.
This removes need to manually create history tables.
Our code still remains in control of when history records are
created.
https://www.pivotaltracker.com/story/show/117920839
On the dashboard we want to show counts of notifications sent in the
last 7 days, plus today. So the API enpoint needs to accept an argument
to limit how many days worth of statistics it will return.
This is a bit fiddly at the DAO level because the date is just stored as
a string.
