Retain data and manage Institutional Managers' privileges upon plugin deactivation

[richard015ar]

Currently, our process involves permanently deleting all data generated by our plugin upon its deactivation. This approach facilitates database version updates during development, as we lack a standardized process for database migrations. This practice poses significant risks in production environments, particularly if plugin deactivation occurs accidentally by PB staff.

Moreover, we've observed that Institutional Managers retain their restricted super admin privileges even after the plugin is deactivated, which could lead to unintended super admin rights.

Proposal:

• Amend the deactivation process to retain plugin-generated data by default when the plugin is deactivated. This change aims to safeguard critical data and ensure its availability even when the plugin is inadvertently deactivated. Another more labor-intensive option would be an optional field/checkbox setting.
• Provide instructions for removing plugin-generated data for anyone who wants to fully remove the plugin and its data.
• For the Institutional Manager permissions, use the revoke_super_admin method and remove their network manager restriction during the deactivation process for all managers in insitutions_users table. When reactivating the plugin, inspect the table again to conditionally restore the restricted super admin privileges to the users.

DoD:

• Reach consensus on the approach for handling plugin-generated data and the management of Institutional Managers' super admin privileges upon plugin deactivation.
• Modify the deactivation process to implement the agreed-upon solution and preserve the data for our production environments.

[richard015ar]

WIP in https://github.com/pressbooks/pressbooks-multi-institution/pull/113

[richard015ar]

I realized we aren't revoking admin privileges to the IM after we delete an institution. There are 3 places where we'd revoke super_admin privileges (and update the site option for network manager Ids):

• when an institution is deleted
• when an institution is updated
• when we run the new command I am creating to reset the DB

I was thinking of using Eloquent events, so we revoke/add privileges each time we add/remove institutional managers (institutions_users). However, it seems that events do not work in our WP context as they would on Laravel. So, after trying it, my next step for tomorrow is going to be to centralize the 3 scenarios in probably one method in the Support.php file, so we can use it in those 3 places.

[tw77]

Followed the testing notes from the PR on dev except for the last one (wp reset-db-schema) to be run on ricardodev instead. Everything is working as expected and restored upon plugin reactivation on dev.

[tw77]

Ricardo and I met and used the command to reset the DB on ricardodev, which worked to delete the relevant data on that network. Everything here is working.