For support tickets, we currently have an "approved" column that saves whether the ticket has been marked as ham (true) or spam (false). We don't do this for abuse reports, and there's no real reason to do it here. We can just run the report through the spam checker and send or reject it based on the results without saving said results to the database.
How to test the Support form: make sure you can still send a Support ticket. Also try sending one with the email field set to firstname.lastname@example.org, and make sure that ticket still gets rejected as spam.
How to test the migration:
1. Run the migration.
2. Copy the commands that it prints to a file.
3. Run the pt-online-schema-change command (but no SQL commands).
4. Submit a new support request.
5. Count the number of rows in feedbacks.
6. Run the SQL commands to swap the tables and drop the old table.
7. Count the number of rows in feedbacks, and make sure it's the same as before.
8. Double-check to make sure that the approved column has been dropped.
Created feedback, email received.
Looks like it mostly ran successfully! But where did the second _feedbacks_old table come from? Did you keep it intentionally to be able to compare? Or is there something wrong with the pt-online-schema-change flags?
Also, do you want me to submit a PR to modify this migration to add the --ask-pass argument, too? Or is the plan to only add it for future migrations, and just add it manually when this migration has to be run?
“_feedbacks_old” I think this turned up because I did a rollback. Or maybe I didn't clean up properly
If you have time to add the --ask-pass then that would be nice but its not blocking. It just means I am less likly to get it wrong.
--ask-pass has been added and merged and deployed to staging, fwiw