Wednesday, September 23, 2026
2 changes · 17.0
Enhancements to existing features
Large inventory transfers with thousands of lines now validate much faster by updating related line items in batches instead of one at a time. This reduces waiting time and database load while keeping the final stock results unchanged.
Original PR description
Our customer has stock.picking with like 2000 rows . They reported that it was slow to validate ### Before this PR _inverse_picked wrote move.move_line_ids.picked one move at a time, so…
Our customer has stock.picking with like 2000 rows . They reported that it was slow to validate ### Before this PR _inverse_picked wrote move.move_line_ids.picked one move at a time, so button_validate on a picking with a couple thousand moves issued one stock.move.line write per move. Each write re-triggers base_automation's write hook, which recompiles every active rule's domain on stock.move.line (safe_eval + compile, never cached). ### After this pr The moves are grouped by their picked value first, then writes each group's move_line_ids once: same end state, same records touched, at most two write calls instead of one per move. Benchmark, 2000 stock.move + 2000 stock.move.line, one active base_automation on_create_or_write rule on stock.move.line, fresh 17.0 database with no demo data: | | queries | time | |---|---|---| | before | 2006 | 3.749s | | after | 6 | 0.489s | 7.7x faster, 334x fewer queries. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fixes an issue where using the chatter on a form could discard unsaved edits if the form could not be saved, such as when a required field was empty. Users now keep their current changes and can correct validation errors without losing their work.
Original PR description
Before this commit, posting a message in the chatter of a form view with `post_refresh` lost the unsaved changes of an invalid record, for instance after emptying a required field. The form showed the invalid field for a moment, then came back with the saved values. The same happens on the other chatter actions that reload the form, such as a follower change. This happens because the chatter reloads the record after it tries to save it, even when the save fails. This commit fixes the issue by reloading the record only when the save succeeds.