You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In most cases, this fix: odoo/upgrade@bc4a020d334ee15263b6f9992528645a17ea000f will not work. These cases occur for databases that already have a migration history (i.e., 16 → 17 → 18) or when a manual upgrade of a module has been performed by the client via the UI. In such scenarios, there is a high possibility that the write_date has been updated by the root user, exceeding the internal time limit (1 minute). Due to which the actual purpose of if_unchanged is not delivered.
Solution:
To handle such cases, a check of the write_uid is essential.
Another scenario would be a record, base.demo, marked as noupdate=True in version A.
Upon upgrading the database to version B, the record undergoes significant changes in the XML.
To update the record, update_record_from_xml is performed during the migration.
This process updates the write_date of the record with the root user.
Now, if a new version C upgrade occurs and the same record is updated using util.if_unchanged(cr, "base.demo", util.update_record_from_xml), it will not be effective in this case.
In most cases, this fix: odoo/upgrade@bc4a020
will not work. These cases occur for databases that already have a migration history
`(i.e., 16 → 17 → 18)` or when a manual upgrade of a module has been performed by the client via the UI.
In such scenarios, there is a high possibility that the `write_date` has been updated by the root user,
exceeding the internal time limit (1 minute). Due to which the actual purpose of `if_unchanged` is not delivered.
To handle such cases, a check of the `write_uid` is essential.
The linked fix can be achieved in a different way. If you provide details in its original PR then it can be done by editing the view directly.
I agree with you. The purpose of this patch was to address the missing link here in is_changed . The whole idea of this patch doesn't limited to the linked fix.
This is not because OdooBot is the last writer that the records hasn't been modified.
Exactly.. That’s what this patch is meant to address—to ensure that the record is modified. This is the primary and major reason for this patch. Otherwise, the util.if_unchanged is not as effective as it is intended to be. The conclusion remains 🤔
Exactly.. That’s what this patch is meant to address—to ensure that the record is modified. This is the primary and major reason for this patch. Otherwise, the util.if_unchanged is not as effective as it is intended to be. The conclusion remains 🤔
No, you are ignoring edits by OdooBot. The fact that it was OdooBot that edited the view is enough reason for us to stop and consider whether the update can be applied. Even though in many cases it could be an update done by a previous upgrade... we simply cannot be sure.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description:
(i.e., 16 → 17 → 18)or when a manual upgrade of a module has been performed by the client via the UI. In such scenarios, there is a high possibility that thewrite_datehas been updated by the root user, exceeding the internal time limit (1 minute). Due to which the actual purpose ofif_unchangedis not delivered.Solution:
write_uidis essential.Another scenario would be a record,
base.demo, marked asnoupdate=Truein version A.Upon upgrading the database to version B, the record undergoes significant changes in the XML.
To update the record,
update_record_from_xmlis performed during the migration.This process updates the
write_dateof the record with the root user.Now, if a new version C upgrade occurs and the same record is updated using
util.if_unchanged(cr, "base.demo", util.update_record_from_xml), it will not be effective in this case.