dati18 opened https://github.com/wbstack/api/pull/1028

Refactor UserTermsOfUseAcceptance and TermsOfUseVersion Models

This PR added a hook to ensure that there is only one active ToU version at a time

https://github.com/wbstack/api/pull/1029

migration update

https://github.com/wbstack/api/pull/1030

dati18 closed https://github.com/wbstack/api/pull/1028

Update tou_version and tou_acceptances migration

I was reminded about the one off CreateFirstTermsOfUseVersionJob.php and UserTouAcceptanceJob.php Laravel Jobs, which we should have really been a part of the Database Migration in PR#977. Having these as Laravel Jobs means that each engineer has to remember to run the jobs whenever they set up the Laravel app (which of course we will forget to do and will no doubt cause issues in the future). I'm also not sure how this will affect any future changes to these tables. When setting up the app for the first time, Laravel will execute all the Database Migrations in a single batch. This makes it difficult, if not impossible, to run these one-off Laravel Jobs at the right time. I.e. before any follow-on migrations modify these tables in such a way that would cause the Laravel Jobs to fail.

At the time of writing, the data in the tou_versions and tou_acceptances has all been derived from data elsewhere. Once we add another ToU version, that will no longer be the case. We have a window of opportunity to do this properly by dropping the existing tables, recreating them with the newly improved schemas, and creating the initial data, all in a single Database Migration (it probably is possible to do it once the second ToU version is added, but it gets more complex).

I imagine this will be done via the following steps:

• First PR and Database Migration:
  • Rename the existing tables to have an _old suffix
  • Create the new tou_versions and tou_acceptances tables with the improved schema
  • Populate the new tou_versions and tou_acceptances tables with data (this will be similar to the steps in the CreateFirstTermsOfUseVersionJob.php and UserTouAcceptanceJob.php jobs)
• Deploy to staging, run the migration, and check the new and _old tables are equivalent
• Second PR and Database Migration:
  • Delete the tables with the _old suffix
  • Delete the CreateFirstTermsOfUseVersionJob.php and UserTouAcceptanceJob.php jobs from the git repo
• Deploy to staging and run the migration
• Deploy the first PR to production, run the migration, and check the new and _old tables are equivalent
• Deploy the second PR to production and run the migration