If you schedule a job you might change your mind or circumstances might
change. So you need to be able to cancel it. This commit adds a `POST`
endpoint for individual jobs which sets their status to `cancelled`.
This also means adding a new status of `cancelled`, so there’s a
migration…
a service now has branding and organisation_id columns, and two new
tables have been aded to reflect these:
* branding is a static types table referring to how a service wants
their emails to be branded:
* 'govuk' for GOV UK branding (default)
* 'org' for organisational branding only
* 'both' for co-branded output with both
* organisation is a table defining an organisation's branding. this
contains three entries, all of which are nullable
* colour - a hex code for a coloured bar on the logo's left
* logo - relative path for that org's logo image
* name - the name to display on the right of the logo
a service now has branding and organisation_id columns, and two new
tables have been aded to reflect these:
* branding is a static types table referring to how a service wants
their emails to be branded:
* 'govuk' for GOV UK branding (default)
* 'org' for organisational branding only
* 'both' for co-branded output with both
* organisation is a table defining an organisation's branding. this
contains three entries, all of which are nullable
* colour - a hex code for a coloured bar on the logo's left
* logo - relative path for that org's logo image
* name - the name to display on the right of the logo
this replaces content_char_count, by performing the additional
steps to calculated billable units at insert time, rather than
read time. This means we can take into account whether the
service was in research mode or using a test api key when the
notification was sent :tada
please ensure that any changes to notifications table happen through either dao_create_notification or dao_update_notification.
changed the notification status update triggered by the provider callbacks to ensure that sets updated_by and can update the history table.
also re-added the character_count so we can reconstruct billing data if needed.
triggered via calls in dao_create_notification and dao_update_notification - if you don't use those functions (eg update in bulk) you'll have to update the history table yourself!
table will be used for storing archival versions of notifications. It's an exact duplicate of notifications table, but with the following modifications:
* removed _personalisation
* removed to
* removed content_char_count
All foreign keys to other tables still exist. additionally, removed defaults (for id and created_at) since they'll be set when we create, and we should ensure that we don't forget about them when inserting/udpating this table.
set to 'normal' for all existing notifications, and all job notifications also created as 'normal' - so if your eg reporting service hits notify, it gets notifications created from both API calls and front-end csv jobs.
It seems like an oversight not to include the notification type in the notifcation.
When updating statistics a query to the template table is required to get the type, this update will mean that query does not have to happen.
* single-column static data table that currently contains two types: 'normal' and 'team'
* key_type foreign-keyed from api_keys
- must be not null
- existing rows set to 'normal'
* key_type foreign-keyed from notifications
- nullable
- existing rows set to null
* api_key foreign-keyed from notifications
- nullable
- existing rows set to null
notifications, when retrieved by notification id, or service id (i.e.
all notifications for service).
There is a new element returned at top level of notification json called
body, which is the template content merged with personalisation. This
is consistent with api to endpoint to create notification which returns
what was sent as 'body' in json response.
Merging of template with personalisation is done in the
NotificationStatusSchema.
Personalisation data in encrypted before storing in db.
Including sms code, email verification, invitation emails, and password reset emails
Added the service id and template ids to config.
Small change to dao_create_service to use id if set.
