- 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.
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
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.
The Celery `send_sms` and `send_email` tasks _could_ assume that all the
recipients it gets are safe, because they have been checked either:
- when the admin app processes the CSV
- in the `/notifications/sms|email` endpoint
*However*, it’s probably safer to make the check again when the Celery
task run and passes the message off to the third party.
This also means that changing a service _back_ to restricted would have
an effect on messages that were queued, as well as all subsequent
messages.
This commit:
- restores the test that was removed here:
e56aee5d1d (diff-e5627619e387fccc04783c32a23e6859L346)
- adds checks back into the Celery tasks for sending email and SMS,
using the `allowed_to_send_to` function that was introduced into utils
in https://github.com/alphagov/notifications-utils/pull/16
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.
If a service is in restricted mode then a user can’t send messages to anyone
other than themselves and members of their team. To do this the API has to
compare the numbers they are sending to with those of their team members.
It will (falsely) say the numbers do not match if they are in a different
format, eg 07700 900849 vs +447700900849
This commit uses the code we use elsewhere for formatting phone numbers to
make sure that both numbers are in a consistent format before doing a
comparison.
I have a strong preference for doing it this way, rather than formatting numbers
before we store them:
1. https://en.wikipedia.org/wiki/Robustness_principle
2. It’s confusing to a user to see their own phone number formatted in a
different way to that which they entered it, and the alternative, storing
the phone number in two different formats is grim
- client updated to raise errors with fire text error codes/messages
New endpoint
- /notifications/sms/firetext
For delivery notifications to be sent to.
- If a job starts it MUST be able to fit into the days sending limits
- So if service limit is 10, and we've sent 5 messages and the current job is 4 then it's OK.
- If the job is 6 then it's over the limit and it should fail
- Job should NOT start if can't complete in the limit
