Thursday, September 3, 2026
2 changes · 17.0
Resolved issues and error corrections
This fix prevents forms with editable line items from failing to save when users add or remove lines very quickly. Visible new or edited lines are preserved, while obsolete background entries are safely ignored so users can complete their work without a client error.
Original PR description
Description of the issue/feature this PR addresses: `StaticList._getCommands` reads `record.resId` for every CREATE/UPDATE command without checking that the row is still in `_cache`. Adding or…
Description of the issue/feature this PR addresses: `StaticList._getCommands` reads `record.resId` for every CREATE/UPDATE command without checking that the row is still in `_cache`. Adding or removing x2many lines faster than onchange/save can leave a stale command whose record is only in `this.records` (or gone entirely). The save then throws `TypeError: Cannot read properties of undefined (reading 'resId')` and nothing is written. Same unguarded lookup on 17.0, 18.0, and 19.0. Issue: https://github.com/odoo/odoo/issues/267847 A bare `if (!record) continue` would stop the crash but drop a visible new line. This recovers from `this.records` when the row is still on screen, then skips only true ghosts. Current behavior before PR: Saving an editable one2many after rapid add/remove (pricelist rules, receipt/PO/SO lines) throws a client error and the form stays dirty. Desired behavior after PR is merged: Save completes. Visible new/edited lines are still written. Stale commands with no matching row are skipped. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Payroll rule parameters are now explicitly sorted before selecting the applicable value. This helps ensure payroll calculations use the most recent correct parameter value rather than an older entry when records are returned out of order.
Original PR description
Normally, rule parameters record values are being sorted already, but in my experience, sometimes when a rule parameter is called, the sorting seems to be off compared to the view. To make sure the result of the call is always the correct value, we need to sort the list before we limit to 1. What I observed was the following: if there are 2 records inputted in the following order (in form [date_from, value]): 1=[01/01/2019,100.00] 2=[01/09/2021,800.00]. On the rule parameter form view it would show record 2 first and then record 1. **This is correct**. However, when calling the parameter, I would receive record 1 value. **This is incorrect**.