Removed the validation in the schema - it was adding complexity, let the unique constraint on the db throw the exception. This should only ever happen on a race condition which seems unlikely (two people changing a service to the same name at the same time)
Do no set debug=true to the test config. If debug=true it changes the behaviour of the error handlers, throwing the exception rather than returning a 500.
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
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
- 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.
