512467788b
Task 16's security group rehoming (fusion_accounting → fusion_accounting_core) only existed in post-migration. That flow fails on fresh pre-Phase-0 upgrades: data-load runs before post-migration and looks up group xml-ids by (module, name); if the row still has module='fusion_accounting', Odoo creates a duplicate res.groups record under module='fusion_accounting_core'. The subsequent post-migration UPDATE...SET module='fusion_accounting_core' then trips the (module, name) unique constraint on ir_model_data, rolling back the whole transaction. Pre-migration runs BEFORE data-load, renames the five security xml-ids (module_category, privilege, three groups) to the new module, so data-load finds the existing rows and UPDATEs them in place. Existing user-group links via res_groups_users_rel are preserved. The post-migration is kept as an idempotent safety net (docstring updated to reflect the new division of labour). Verified on westin-v19 by simulating the pre-Phase-0 state (UPDATE ir_model_data SET module='fusion_accounting' ...) and re-running the upgrade: 5 rows renamed cleanly, zero duplicates, no errors. Made-with: Cursor