-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove emergency alerts code #3976
base: main
Are you sure you want to change the base?
Conversation
At the moment if you try to view a broadcast template in the admin app you will get an exception (the app doesn’t know how to preview one of these templates). But the only way you can get to that page is by manually entering the We could put in a workaround to return a |
i think to start with we could put 404s on any broadcast template or broadcast service endpoint, and then delete the data later i'd be keen on deleting the data in the DB earlier rather than later so we dont get surprised by weird data if we want to update schemas on those tables or migrate data based on columns listed in the models or things like that |
FYI, we can't delete any of the broadcast data out of our database for 1 year please. Either that or we need to take a snapshot of that data and store it elsewhere for a year. This is because emergency alerts need it as an audit trail for any security incidents (precedent is to store it for a year, just like Notify does). The 1 year is from the time they migrated to their own system (was that like early November maybe?) |
thanks, that's useful to know david. I'd probably be keen on snapshotting and storing it in a pgdump in s3 ideally |
bbf8b56
to
4bbec83
Compare
4bbec83
to
c6d66eb
Compare
c6d66eb
to
85bbc98
Compare
this is a data migration (so no downgrade) that deletes broadcast services and all associated data - this includes obvious things like broadcast events and templates, but also everything connected to those services like user permissions, inbound senders, ft_billing rows, etc Although some of these theoretically shouldn't exist for broadcast services (eg returned_letters), issue the deletes out of an abundance of caution. These migrations need to pass on preview and staging as well as production, and for example there was a broadcast service on staging with an inbound sms number This has been tested against a copy of the staging database.
85bbc98
to
9ce67d6
Compare
no longer used. there might be additional cleanup we can do of other utils functions that dont have "alert" or "broadcast" in the name that are no longer used
the schema was originally created so that it could not show content. However, then it needed content conditionally for broadcast messages so content was added back in. Now that broadcasts no longer exist we can revert that - however, for a template that has a specific list of expected keys, it's nicer to just list those rather than maintain a huge list of exceptions that needs to be modified every time a field changes on the template model
9ce67d6
to
dd6210a
Compare
This doesn't deal with any database migration, but it does get rid of all code.
TODO before we merge: