If the notification has a status == sending then update the status otherwise do not update the status.
In other words do not change the status more than once.
- new client for statsd, follows conventions used elsewhere for configuration
- client wraps underlying library so we can use a config property to send/not send statsd
Added statsd metrics for:
- count of API successful calls SMS/Email
- count of successful task execution for SMS/Email
- count of errors from Client libraries
- timing of API calls to third party clients
- timing of how long messages live on the SQS queue
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.
This version of the client removed the request method, path and body from the encode and decode methods.
The biggest changes here is to the unit tests.
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
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.
Refactor process_firetext_responses
Removed the abstract ClientResponses for firetext and mmg. There is a map for each response to handle the status codes sent by each client.
Since MMG has about 20 different status code, none of which seem to be a pending state (unlike firetext that has 3 status one for pending - network delay).
For MMG status codes, look for 00 as successful, everything else is assumed to be a failure.
Implements
https://github.com/alphagov/notifications-utils/pull/16
Once
https://github.com/alphagov/notifications-admin/pull/376
is merged it will no longer be possible for a user to upload a CSV file
containing recipients that they’re not allowed to send to.
So this commit also removes any restricted service checks in the task,
because any public phone numbers/email addresses no longer have any way
of reach this point if the service is restricted.
This PR removes the need for the email_safe function. The api does not create the email_from field for the service.
Tests were updated to reflect this change.
- when a provider callback occurs and we update the status of the notification, also update the statistics table
Adds:
- Mapping object to the clients to handle mapping to various states from the response codes, this replaces the map.
- query lookup in the DAO to get the query based on response type / template type
Tests around rest class and dao to check correct updating of stats
Missing:
- multiple client callbacks will keep incrementing the counts of success/failure. This edge case needs to be handle in a future story.
- SES/AWS JSON is horrible and not valid.
- JSON in tests did not test accurately what it looked like in reality
- Using very odd looking bytes/strings as input into API which is more accurate
- SES sends a reference to allow us to identify the notification
- use this to update status
If source of email is one of our internal emails (invites or validations) - don't try and update a notification.
- client updated to raise errors with fire text error codes/messages
New endpoint
- /notifications/sms/firetext
For delivery notifications to be sent to.
