upgrade-util
upgrade-util copied to clipboard
odoo
[IMP] util/records: enforce `cascade` removal for actions
The implementation of the python inheritance mechanism between the base class ir.actions.actions and its child classes (eg. ir.actions.act_window) does not allow the creation of foreign keys when ir.actions.actions is a M2O field of another model; what leads to the not execution of some constraints, one of them being the ondelete='cascade' constraint, which is set in PSQL level.
That said, when a ir.actions.actions record is deleted, if it is being referenced as a M2O field by another model (eg. ir.filters), records from this second model won't be affected, what leads to undesired behaviour: a MissingError in the UI, indicating that the action was deleted.
Such behaviour of not creating foreign keys and thus constraints is specific to ir.actions.actions.
This commit remedies this specific case, removing records with a M2O field to ir.actions.actions with ondelete=cascade when the action referenced in such field is removed using upgrade-util.
I do not intend to leave these NOTES in the final diff, these are only for discussions in this PR
You could move the notes from the code to the PR. Add them as comments here.
Hey I believe we can revert the following PR https://github.com/odoo/upgrade/pull/5869 before this ~~once~~ is merged
Hey I believe we can revert the following PR odoo/upgrade#5869 before this ~once~ is merged
No, this is still needed for actions not deleted via this new helper.
Any news here? I've discovered another issue with filters on an upgrade project, though it's not related to upgrading technically -> install a module, like hr_holidays, save a filter, uninstall the module = the filter is now corrupt because of the missing model in registry:
IMO, apart from this util helper, either:
1 - have a base script in upgrade that fixes the filters on upgrade, removing ones that have missing actions like the example in this PR and were NOT deleted with this helper, and removes also ones with missing model like I describe above
2 - I fix this in a PR to odoo to cleanup the filters on module / model removal
wdyt? @aj-fuentes @KangOl
@erl-odoo The uninstall process of standard Odoo is full of corner cases where data is left in a wrong state, this is yet another example :)
IMO yes you can try to fix the standard process to cleanup those filters in master odoo. During upgrades, removing what seems to be broken filters may be acceptable, but we usually try to avoid removing data (they may work in case the model re-appears after a reinstall). Generally speaking, if it was broken before the upgrade and doesn't fail the upgrade, we don't fix it.