Thursday, September 3, 2026
3 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
Express checkout now stops payment if the customer's billing address changes the applicable tax rules after the original quote. This prevents customers from being charged a different amount than they approved and asks them to review the refreshed total before retrying.
Original PR description
Issue: process_express_checkout assigns partner_id directly on an anonymous cart (removing pricelist_id from the fields to recompute, to keep the pricelist stable), so the address update is never…
Issue: process_express_checkout assigns partner_id directly on an anonymous cart (removing pricelist_id from the fields to recompute, to keep the pricelist stable), so the address update is never called. The order fiscal_position_id still refreshes via its stored compute, but the line tax_id stays with the previous mapping: _compute_tax_id does not depend on fiscal_position_id, so it is never re-triggered. The invoice is then posted with the wrong VAT. Recomputing the taxes silently on the backend is not enough: the customer already approved a total in the native express payment sheet (Apple Pay, Google Pay or Link), and we never update that amount. They would then be charged a different, higher total than the one they accepted. Fix: When the billing address resolves to a different fiscal position than the one used to quote the displayed amount, recompute the taxes and abort the payment: the endpoint returns False and sets a shop_warning, and the Stripe express checkout form reloads the page so the customer sees (and re-accepts) the refreshed prices before retrying. _recompute_taxes is wrapped in a try/except UserError to avoid blocking the flow if an external tax computation (e.g. Avatax) fails. Steps to reproduce: - Configure the company with two auto-applied fiscal positions, e.g. a domestic one (Luxembourg, 3% sale tax) and an "Extra-Community" one that maps the domestic tax to 0% EC for non-EU countries. - Configure Stripe with an express payment method (Apple Pay, Google Pay or Link). - Log out and browse the shop with a geoip pointing to a non-EU country so the cart picks up the "Extra-Community" fiscal position. - Add a product to the cart. - Observe: the cart line has the 0% EC tax. - Trigger the express payment button and pay using a billing address located in the domestic country (Luxembourg). - Observe on the confirmed order: fiscal_position_id is the domestic one but the line tax_id still holds the 0% EC tax. The invoice is posted with 0% VAT instead of the expected 3%. opw-6213195 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- 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**.