Creates the column as nullable, sets the value to false for all
existing templates and template versions and then applies a
not-nullable constraint.
All future Templates are created with `False` as the default set
in SQLAlchemy.
we have problems where govuk service is not migrated to sms_senders on new datbases.
update this old script so we don't affect live systems, but when people rebuild their
database from scratch they get the sms sender for govuk notify.
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.
