[19.0][FIX] upgrade_analysis: don't reset foreign-module fields on moved noupdate records#3677
Conversation
|
Hi @StefanRijnhart, @legalsylvain, |
|
That is not the correct use of |
|
Ok, fixed PR message, by referencing the PR instead of the commit. |
hbrunn
left a comment
hbrunn
left a comment
There was a problem hiding this comment.
please amend test_analyze with some data and probably a patch on the fields to cover most of the code introduced here
13c0afc to
155b8b9
Compare
…update records When a noupdate record is moved to another module, its previous definition may set a field declared in a module the new one doesn't depend on (e.g. a module that depends on it). That field is still managed by its own module, so skip it instead of resetting it to its default in the new module's noupdate_changes.xml.
…anged When a noupdate field set in the previous version is dropped in the current one, only write the reset to noupdate_changes.xml if the value a fresh install would give the field actually differs from the previous value. Otherwise the (noupdate) record already holds the right value and the entry is a no-op.
155b8b9 to
d3168b0
Compare
|
/ocabot merge patch |
|
What a great day to merge this nice PR. Let's do it! |
|
Congratulations, your PR was merged at bbe30db. Thanks a lot for contributing to OCA. ❤️ |
5 participants
When a noupdate record is moved to another module, its previous definition may set a field declared in a module the new one doesn't depend on (e.g. a module that depends on it). That field is still managed by its own module, so skip it instead of resetting it to its default in the new module's noupdate_changes.xml.
Fixes #3671.
Detected in OCA/OpenUpgrade#5828 (in
hr_holidaysmodule, inholiday_status_extra_hoursxmlid, that comes fromhr_holidays_attendance).