This changeset fixes a blocking error with the DB export script which failed when it came across data linking the users table to a permissions table, which up until now had been empty. (Adding a non-superuser User to the CMS admin created a row in the auth_user_group table, which previously had been empty.)
[ ] I used an AI to write some of this code.
Significant changes and points to review
This changeset:
Fixes the blocking error when exporting a source DB where the auth_user_groups and/or auth_user_user_permissions tables have data
These two tables have a non-NULL user_id column, which means that the script is now failing because it could not nullify rows in those tables. The data for those rows was being pulled over via FK constraints because we exported the auth.User model from the source DB.
The fix was to ensure that we were actually purging those two tables as well as the auth_user table (which we were doing already).
Also, the ordering of operations needed to be addressed: clearing the tables before running the nullifying-relations code, rather than after, to avoid integrity issues because of that un-nullable auth_user_groups.user_id.
I've tested this locally and putting the nulling after the table deletion seems to be fine: nullable columns are nulled and no data appears to cascade-delete when auth_user, auth_user_groups or auth_user_user_permission is dropped. If cascading deletion was going to occur, we would already have seen it with the deletion of auth_user, regardless of when it's called in the export script.
Update output to make more sense in terms of ordering of messages if we do fail to purge key tables
Improve comment to help with running it in debug mode
Issue / Bugzilla link
No ticket/issue - hotfix
Testing
I've tested this locally and once it hits main i'll re-test on real dev data and pull the DB down to my machine
One-line summary
This changeset fixes a blocking error with the DB export script which failed when it came across data linking the users table to a permissions table, which up until now had been empty. (Adding a non-superuser User to the CMS admin created a row in the
auth_user_grouptable, which previously had been empty.)Significant changes and points to review
This changeset:
Fixes the blocking error when exporting a source DB where the
auth_user_groupsand/orauth_user_user_permissionstables have dataThese two tables have a non-NULL
user_idcolumn, which means that the script is now failing because it could not nullify rows in those tables. The data for those rows was being pulled over via FK constraints because we exported theauth.Usermodel from the source DB.The fix was to ensure that we were actually purging those two tables as well as the
auth_user table(which we were doing already).Also, the ordering of operations needed to be addressed: clearing the tables before running the nullifying-relations code, rather than after, to avoid integrity issues because of that un-nullable
auth_user_groups.user_id.I've tested this locally and putting the nulling after the table deletion seems to be fine: nullable columns are nulled and no data appears to cascade-delete when
auth_user,auth_user_groupsorauth_user_user_permissionis dropped. If cascading deletion was going to occur, we would already have seen it with the deletion ofauth_user, regardless of when it's called in the export script.Update output to make more sense in terms of ordering of messages if we do fail to purge key tables
Improve comment to help with running it in debug mode
Issue / Bugzilla link
No ticket/issue - hotfix
Testing
I've tested this locally and once it hits main i'll re-test on real dev data and pull the DB down to my machine