mirror of
https://github.com/GSA/notifications-api.git
synced 2026-01-24 19:41:50 -05:00
ce2f550387
At the moment, we currently have broadcast services that have the 'broadcast' service permission in the DB but don't have a corresponding row in the service_broadcast_settings table. It's important to give them a row in this table because this will control which broadcast channel their messages will go out on. All broadcast services will be expected to have this row so we can then remove hardcoded defaults from our code that currently set what channel a message should go out on. Whilst, when this gets deployed, we will have released https://github.com/alphagov/notifications-admin/pull/3794, which means that when a service setting is changed via that form, they will get the corresponding row in the service_broadcast_settings form, we don't want to ask every developer to go and fill in this form for every service on their local dev environment and also do the same to every service we have in preview, staging and production. Therefore a migration is the best way to backfill the data. Note, I made the decision that a service that is in trial mode will be given the 'severe' channel. This is because this is what most trial mode services should have. Only the MNOs would ever really have a trial mode service on the test channel. And given they are in trial mode, it is not too risky to give them the 'severe' channel. For services that are live though, although there are no services in production that have the broadcast permission and are live, it is not worth taking that risk and accidently setting that service to send an alert out on the 'severe' channel. We play it say by choosing 'test'.
Generic single-database configuration.
flask db migrate to generate migration script.
flask db upgrade to upgrade db with script.
flask db downgrade to rollback db changes.
flask db current to show current script.