This is the schema that individual notifications will conform to
when they are returned from this API.
JSON logic enforces that the right keys are set depending on the
`"type"`. (eg a schema with `"type": "sms"` must have a
`"phone_number"` value and it cannot have an `"email_address"`)
The new 'v2' API wants to return less data than the previous one,
which was sending back tons of fields the clients never used.
This new route returns only useful information, with the JSON
response dict being built up in the model's `.serialize()` method.
Note that writing the test for this was a bit painful because of
having to treat loads of keys differently. Hopefully we think this
is a good way to write this test, because if we don't, we should
start thinking of a better way to check the values are what we
expect.
In the V2 API, the GET response for an individual notification
returns a 'cost' value, which we can get by multiplying the
billable units by the per-message rate of the supplier who
sent the message.
Any notifications with billable units > 0 but without a
corresponding `ProviderRates` entry will blow up the application,
so make sure you've got one.
Update the format_checkers to raise the specific exception that why the validator can handle multiple messages.
Which led to a refactor of build_error_message.
Two different versions of 0059 were merged.
`0059_set_services_to_active` was merged first, so this renames my
migration to `0060`, so it goes in afterwards.
this means that any errors will cause the entire thing to roll back
unfortunately, to do this we have to circumvent our regular code, which calls commit a lot, and lazily loads a lot of things, which will flush, and cause the version decorators to fail. so we have to write a lot of stuff by hand and re-select the service (even though it's already been queried) just to populate the api_keys and templates relationship on it
A letter type was added to the `enum` in the `Template` model at the
same it was added to the `Notification` model. But the migration was
only done for the `notifications` table, not the `templates` table.
See: https://github.com/alphagov/notifications-api/commit/25db1bce#diff-516aab258e161fc65e7564dabd2c625aR19
This commit does the migration to add `letter` as a possible value for
the `template_type` column, which is a bit fiddly because `enum`s.
Before:
```
notification_api=# select enum_range(null::template_type);
enum_range
-------------
{sms,email}
(1 row)
```
After upgrade:
```
notification_api=# select enum_range(null::template_type);
enum_range
--------------------
{sms,email,letter}
(1 row)
```
After downgrade
```
notification_api=# select enum_range(null::template_type);
enum_range
-------------
{sms,email}
(1 row)
```
