Odoo Changelog — 2026-08-27

Thursday, August 27, 2026

4 changes · saas-18.3

Bug Fixes(4)

Resolved issues and error corrections

[FIX] base: SetDefinitions can have mutliple refs

Coresaas-18.3base

This fixes cases where the same user group is known by more than one internal identifier, but access checks only recognized one of them. It helps ensure users get the correct permissions consistently when modules refer to the same group by different names.

Original PR description

A group can be identified by multiple xmlids. We add support to provide a list of "refs" to the `SetDefintions` object.

Reproductible issue:
```
demo = self.env["res.users"].browse(5)
demo.has_group("accountant.group_account_user")  # False
demo.has_group("account.group_account_user")  # True
assert self.env.ref("accountant.group_account_user") == self.env.ref("account.group_account_user")
```

task-6471260



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#groups#permissions#access-rights

[FIX] web: reserve unsaved edits when dragging Translation dialog

PR #284407

Coresaas-18.3web

This fix prevents unsaved translation text from being lost when a user drags the translation dialog. It helps users safely reposition the window while entering translations without having to retype their work.

Original PR description

Step to reproduce:
- have atleast two language and install sale
- open any product, hover over product, and click on Translation button
- Enter a value for one of language
- drag the dialog

Observation:
- we lose the data, we just entered and fallback to original data

Cause:
- Inputs used `t-att-value="term.value"`, bound to original data. Since this content is passed to Dialog via slot, it is rendered/patched as part of Dialog's render cycle,
- Dragging updates Dialog's state, triggering a patch that re-evaluated the slotted template and reset input values (which comes from `term.value`)

Fix:
- bind value to `updatedTerms[term.id] ?? term.value` so edits survive patches triggered by the parent Dialog

opw-6431521


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#283514

#translations#dialog#unsaved edits

[FIX] website_sale: prevent recordset leak in cart line class

PR #285014

Coresaas-18.3website_sale

This fixes a small display issue in the online shop cart where hidden technical text could be added as a page styling marker. Customers should see no visible change, but the cart page markup is now cleaner and behaves as intended.

Original PR description

The t-attf-class expression on the cart product line used the Python 'and' operator without a fallback: 'line.linked_line_id and "optional_product info"'.

When linked_line_id is an empty recordset (falsy), Python's 'and' returns the falsy operand itself instead of an empty string. QWeb then interpolates that operand into the class attribute via str(), rendering the literal 'sale.order.line()' as a CSS class on every cart line without a linked_line_id.

Adding 'or ...""' forces the expression to fall back to an empty string when linked_line_id is falsy, restoring correct conditional class rendering consistent with the adjacent attrs in the same t-attf-class.


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#284835

#ecommerce#cart#styling

[FIX] base_vat: prevent truncation of vat string in warning message

PR #284305

Coresaas-18.3base_vat

Invalid VAT warnings now preserve and display the exact VAT number entered by the user, instead of accidentally dropping part of the country prefix. This makes validation errors clearer and helps users identify and correct the problematic input faster.

Original PR description

Before this change:
When entering or importing a VAT number (e.g., CHE-115.391.649), an invalid 
VAT warning displays a string missing its country_id (e.g., E-115.391.649).
This confuses users and masks the actual input string that triggered the validation 
failure.

To reproduce:
1. Open any contact record and set the Country to Switzerland.
2. Enter an invalid or manually formatted Swiss VAT number like `CHE-115.391.649`.
3. Save or trigger the VAT validation check.
4. Observe the warning banner showing `E-115.391.649` instead of `CHE-115.391.649`.

After this change:
The validation warning logic preserves the original user input when constructing the 
alert message, ensuring error notifications accurately display VAT number.

Issue introduced by:
* https://github.com/odoo/odoo/commit/ac95d2d6d80a368dfb190d0ac21da2af479a8488
* https://github.com/odoo/odoo/commit/a2afe3292e1cd0a4f339dc47707e469653d13ea0

opw-6474217

#vat#validation#contacts#warning

A group can be identified by multiple xmlids. We add support to provide a list of "refs" to the `SetDefintions` object. Reproductible issue: ``` demo = self.env["res.users"].browse(5) demo.has_group("accountant.group_account_user") # False demo.has_group("account.group_account_user") # True assert self.env.ref("accountant.group_account_user") == self.env.ref("account.group_account_user") ``` task-6471260 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Step to reproduce: - have atleast two language and install sale - open any product, hover over product, and click on Translation button - Enter a value for one of language - drag the dialog Observation: - we lose the data, we just entered and fallback to original data Cause: - Inputs used `t-att-value="term.value"`, bound to original data. Since this content is passed to Dialog via slot, it is rendered/patched as part of Dialog's render cycle, - Dragging updates Dialog's state, triggering a patch that re-evaluated the slotted template and reset input values (which comes from `term.value`) Fix: - bind value to `updatedTerms[term.id] ?? term.value` so edits survive patches triggered by the parent Dialog opw-6431521 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283514

The t-attf-class expression on the cart product line used the Python 'and' operator without a fallback: 'line.linked_line_id and "optional_product info"'. When linked_line_id is an empty recordset (falsy), Python's 'and' returns the falsy operand itself instead of an empty string. QWeb then interpolates that operand into the class attribute via str(), rendering the literal 'sale.order.line()' as a CSS class on every cart line without a linked_line_id. Adding 'or ...""' forces the expression to fall back to an empty string when linked_line_id is falsy, restoring correct conditional class rendering consistent with the adjacent attrs in the same t-attf-class. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#284835

Before this change: When entering or importing a VAT number (e.g., CHE-115.391.649), an invalid VAT warning displays a string missing its country_id (e.g., E-115.391.649). This confuses users and masks the actual input string that triggered the validation failure. To reproduce: 1. Open any contact record and set the Country to Switzerland. 2. Enter an invalid or manually formatted Swiss VAT number like `CHE-115.391.649`. 3. Save or trigger the VAT validation check. 4. Observe the warning banner showing `E-115.391.649` instead of `CHE-115.391.649`. After this change: The validation warning logic preserves the original user input when constructing the alert message, ensuring error notifications accurately display VAT number. Issue introduced by: * https://github.com/odoo/odoo/commit/ac95d2d6d80a368dfb190d0ac21da2af479a8488 * https://github.com/odoo/odoo/commit/a2afe3292e1cd0a4f339dc47707e469653d13ea0 opw-6474217