Will specifically affect the email auth template, which was seeded
without a matching row in the `template_redacted` table.
Effectively re-runs c24edcf388
> add historical redaction data
>
> every current template gets a row in the template_redacted table -
> this inserts one for any template that doesn't already have a row,
> with redact set to false, the user set to NOTIFY_USER since it was
> just a script, and the updated_at set to the time the script is run
The default for the rate_limit column in the services and
services_history model is now set in the model, so we can remove the
default from the database.
Pivotal story: https://www.pivotaltracker.com/story/show/153992529
The API rate limit will be removed from the config and added to services
so that it is possible to change the rate_limit for individual services
in rare cases.
Pivotal story: https://www.pivotaltracker.com/story/show/153992529
There is no need for the extra column.
If a template does not have a default address set - they address will be blank.
Otherwise use the address of the service_letter_contact.
There will be another PR to do a db migration.
Template.service_letter_contact = blank if no service_letter_contacts for service ELSE use set Template.serivce_letter_contact_id = service default service_letter_contact
If is_letter_contact_blank then the user has set the letter contact block to be blank on purpose
ELSE IF is_letter_contact_blank is false THEN use the template default
IF template default is blank THEN the service_letter_contact is blank use the service default
- Added the boolean 'crown' column to services and services_history tables
- We populate this column in the same migration script by checking the
'organisation_type' of a service
This is text value of the sender_id, depending on the channel this will be a SMS sender, email reply to address or a letter contact block.
This is the first PR in a series to refactor how we send the "reply_to" the provider, eventually we can eliminate the notification_to_sms_sender and notification_to_email_to tables.
Removes "NOT VALID" mark from the notifications -> template_history
foreign key constraint by validating existing records.
From postgres docs:
> This form validates a foreign key or check constraint that was
> previously created as NOT VALID, by scanning the table to ensure there
> are no rows for which the constraint is not satisfied. Nothing happens
> if the constraint is already marked valid.
> Validation can be a long process on larger tables. The value of
> separating validation from initial creation is that you can defer
> validation to less busy times, or can be used to give additional time
> to correct pre-existing errors while preventing new errors. Note also
> that validation on its own does not prevent normal write commands
> against the table while it runs.
> Validation acquires only a SHARE UPDATE EXCLUSIVE lock on the table
> being altered. If the constraint is a foreign key then a ROW SHARE
> lock is also required on the table referenced by the constraint.
We have now:
- defaulted new services to start with this column set to `true`
- migrated all preexisting services[1] to have either `true` or `false` set
for this column
There is no way for a service to switch back from `true`/`false` to
`null`.
This means that we can safely enforce a non-nullable constraint on this
column now.
1. There is a little gotcha: the GOV.UK Notify service still relies on
the `sms_sender` column. It doesn’t have a row in the
`service_sms_senders` table. This means the previous migration
never changed this service’s value for `prefix_sms` from `null`. So
this commit also changes its value to `False`, so that the rest of
the migration, of the whole column, is possible.
