This uses the `format_phone_number` method from utils to output phone numbers
in a consistent format. It is added to the schemas, so will be applied before
the API tries to do anything with a provided phone number.
So now the API will accept any of the following:
- 07123456789
- 07123 456789
- 07123-456-789
- 00447123456789
- 00 44 7123456789
- +447123456789
- +44 7123 456 789
- +44 (0)7123 456 789
…but the API will always hand off phone numbers to 3rd party APIs in the format
- +447123456789
The test for this is slightly convoluted, because template IDs are still
database IDs, and can’t consistently be mocked, therefore we have to ignore that
part of the call to `encrypt()`.
This was added to utils in 5914da74f1
This means that:
- we are doing the exact same validation in the API and admin app
- we are actually validating phone numbers for the correct format (hence all the
changes to the tests)
This commit allows the send notification endpoint to accept an extra parameter,
`personalisation`, the contents of which will be used (later) to replace the
placeholders in the template.
It does validation in the following places:
- at the schema level, to validate the type and (optional) presence of
personalisation
- at the endpoint, to check whether the personalisation provided matches exactly
the placeholders in the template
It does not do validation when processing CSV files, as these are assumed to
already have been validated by the admin app.
It explicitly does not persist either the names of the placeholders (these
should always be derived from the template contents unless it really becomes a
performance concern) or the values of the placeholders (because they might be
personal data).
Droped token as later code to send email invite can generate
timebased url to send to user. That can then be checked
against configurable time threshold for expiry. Therefore
no need to store a token.
- single base method to send notifications
- knows about service id (present if job based)
- knows about jobs - if needed
- knows about type
Does the right thing
Was lots of shared code around error checking now in one place.
- uses the new subject/email from fields present on the templates / service tables
- brings the send email api call into line with the sms one.
- same fields (to/template_id)
- same rules regarding restricted services
- wired in as a task into celery
Requires
- new celery queue
- new env property (NOTIFY_EMAIL_DOMAIN)
- Created new endpoint user/<user_id>/sms-code to send the sms verification code to the user.
- Create new endpoirtn user/<user_id>/email-code to send the email verifcation code to the user.
- Marked the old methods, schema, tests with a TODO to be deleted when the admin app is no longer sending messages to /user/<user_id>/code
- Added error handlers for DataError and NoResultFound. Data error catches invalid input errors.
- Added error handler for SqlAlchemyError which catches any other database errors.
- Removed the need for the try catches around the db calls in the user endpoints with the addition of the db error handlers.
- We may want to wrap db excpetions in the dao, if we want the No results found message to be more specific and say no result found for user.
Once removal of code that uses existing alpha is done, then
duplicated code from /notifications/sms and the new endpoint
can be merged.
Job id is now avaiable in notificaiton but is not used yet.
Ideally all the primary keys in the db would be UUID in order to guarantee unique ids across distributed dbs.
This updates the services.id to a UUID. All the tables with a foreign key to the services.id are also updated.
The endpoints no longer state a data type of the <service_id> path param.
All the tests are updated to reflect this update.
The thing to pay attention to is the 0011_uuid_service_id.py migration script.
This commit must go with a commit on the notifications_admin app to keep things working.
There will be a small outage until both deploys have happened.
Previously we were using a schema that mapped onto db.Model. However, the json
in the request did not reflect the VerfiyCode db Model.
I did not add validation on the to field, we did not have that previously.
