Thursday, September 17, 2026
2 changes · saas-19.1
Enhancements to existing features
Product variant names now load more efficiently by avoiding unnecessary checks across all attribute values. This can significantly reduce waiting time in large product catalogs, with the reported case improving Point of Sale loading from about 200 seconds to 70 seconds.
Original PR description
Issue --> `product.product's` display_name appends the variant's combination name, which `_get_combination_name` builds by dropping the values that come from single value lines. The check behind that, `_is_from_single_value_line`, only needs to know whether the line holds exactly one active value, but it filtered the line's entire set of values through `_only_active()` to find out. That check runs once per attribute value of every variant being named, so its cost follows the number of values on the template rather than the number of lines. Solution --> Stop at the second active value instead: finding two is enough to know the line is not single valued. The archived path (only_active=False) only measures the line's length and is unchanged, as is the returned name in both cases. Benchmark -> Reading display_name for the 23989 variants on the related database loads in the Point of Sale from approximately 200s to 70s. opw-6530735 Forward-Port-Of: odoo/odoo#288183
Resolved issues and error corrections
Fixes an issue where some spreadsheets with repaired version histories could display or restore an incorrect past version. The change makes Odoo detect this broken history pattern and rebuild the version view from the right saved snapshot, reducing the risk of users accidentally corrupting spreadsheets when restoring older versions.
Original PR description
…heet history Some spreadsheet can end up in a corrupted history state Original Data ⮕ no revision (XX) ⮕ Snapshot ⮕ Active Revisions and where the original data differ from the snapshot. XX: can…
…heet history Some spreadsheet can end up in a corrupted history state Original Data ⮕ no revision (XX) ⮕ Snapshot ⮕ Active Revisions and where the original data differ from the snapshot. XX: can occur after the script added https://github.com/odoo/upgrade/issues/6340. The migration script is supposed to rewrite the history of the spreadsheet when there are holes in the archived revisions continuity (eg. the history was original Data ⮕ rev **A** ⮕ rev **B** ⮕ rev **C** ⮕ snapshot ⮕ rev **D** and user deleted rev **B** for instance, the script deletes **A** and **C** and marks **D** as the very first revision). Version history was designed with the idea to replay every single revision that existed since the creation of the spreadsheet and apply it to the original data, and in case of missing revisions, in our example, B is missing, we detect the lack of continuity, we start from the snapshot, and replay every single revision since that snapshot. When the migration fixes the continuity, by deleting all the old revisions, and changing their order, we can no longer detect the lack of continuity and end up replay every available revision to the original data ,even though they are based on the snapshot. In that scenario, since the revisions will be applied on the original data but since they are based on the state of the snapshot only, the final state of the spreadsheet will be corrupted since a part of the . If a user then decides to restore the spreadsheet to the version they see in the version history (which is corrupted as mentioned) and the last snapshot is overwritten with the corrupted state, effectively breaking the spreadsheet. With this revision, we add a detection of this corrupted history state, in which case we enforce the history to be replayed from the snapshot and not the original data. Task-6533708 Forward-Port-Of: odoo/enterprise#131730 Forward-Port-Of: odoo/enterprise#130649