There was a situation where the SMS was sent, the request timed out we got a 503 so the notification was put on the retry queue. However, the provider got the notification and sent the message. This means we didn't set the billable_units on the notification and the service will not be billed.
This PR is to fix the notifications that we can accurrately update.
This data includes service and org name, consent to research,
contact details and both intended and factual notifications
volumes by notification type.
This query was created to get data for a csv report for our
platform admins.
This PR adds a function to upsert (insert or update if exists) NotificationHistory all the rows from Notification that we are about to delete in the nightly task. This will happen just before the delete function. Since it is a upsert query the function can be called more than once.
This should allow us remove all the insert/updates to NotificationHistory.
However, there is a consern that this will double the length of time the tasks take. So do we do these upserts in a separate task or in the same one?
Bumped utils to version 31.2.5, which changes when the rows of a
RecipientCSV get created. Switched to using `.get_rows()` from
RecipientCSV (a generator) instead of the `.rows` property (which builds
a list of the rows in memory).
Setting `STATSD_HOST` for an env variable allows us to switch to a
local statsd_exporter on a per-app basis.
This also changes `STATSD_ENABLED` to be on when `STATSD_HOST` is set,
avoiding the need to set it separately.
go_live_user_id: is the user that requested the service to go live
go_live_at: is the DateTime the service went live.
There will be a data migration from the beta partners spreadsheet to back fill the data.
This relationship is via the `Organisation` now; we don’t use this
column to fudge a relationship based on the user’s email address and the
matching something in these columns.
Similar to MMG, there's a new env variable FIRETEXT_URL that can be
used to override the Firetext api URL.
This will be used to stub out both providers during the load test or
can be used to run a local API against a fake provider endpoint.
Needed to update old migration scripts so that the email_branding name is not null when creating the test dbs.
This should no affect the migrations elsewhere.
The NHS is a special case because it’s not one organisation, but it does
have one consistent brand. So anyone working for an NHS organisation
should have their default branding set when they create a service, even
if we know nothing about their specific organisation.
