Thursday, August 27, 2026
14 changes · saas-18.3
Security fixes and vulnerability patches
Portal access tokens are now checked using exact matches only, preventing near-matches or partial values from being accepted. This strengthens portal access controls and helps ensure that shared links or protected records are only opened with the correct token.
Original PR description
Access tokens can only be matched by exact value. Task-6481193
Enhancements to existing features
Italian electronic invoice XML files can now be imported without relying on a specific file name pattern. This makes imports more reliable when suppliers or systems use custom file names, reducing manual corrections for users.
Original PR description
With this commit: - We remove the regex check on the imported file name. - The behavior before was checking the filename to fill data into the invoice. - This should not be constrained so that we can ignore the filename Task [link](https://www.odoo.com/odoo/project.task/6152773) task-6152773 Forward-Port-Of: odoo/odoo#277690
Resolved issues and error corrections
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-prClosing point of sale sessions with many invoiced bank payments is now much faster and less likely to time out. The process batches payment reconciliation and invoice receivable line creation, reducing a customer case from over nine minutes to under one minute.
Original PR description
Steps to reproduce ------------------ 1. On a bank payment method, enable "Identify Customer". 2. Create a lot of orders paid with this method and invoice them (the customer reporting the issue had…
Steps to reproduce ------------------ 1. On a bank payment method, enable "Identify Customer". 2. Create a lot of orders paid with this method and invoice them (the customer reporting the issue had 2081 orders). 3. Close the session. The close takes several minutes, and on a remote database the request is killed by the worker time limit before it completes. Cause ----- `_reconcile_account_move_lines` reconciles each group of lines with its own `reconcile()` call, one per payment. Every call creates its partials and triggers the recompute cascade of the ORM, which searches `account.move.line` over the whole set of payments of the session, so the cost of a single call grows with the number of payments. `_create_invoice_receivable_lines` has the same shape: the values are grouped per payment, so every group holds a single value and the lines are created one `create()` call at a time. opw-6242303 already batched the creation and the posting of the split bank payments, and the reconciliation of their receivable lines, but only for the orders that are not invoiced. Invoiced orders go through `split_inv_payment_receivable_lines`, which was left untouched. Fix --- Gather every reconciliation of the session into a single `_reconcile_plan` call. The entries of the plan are processed independently and in order, so the result is the same as reconciling them one by one, but the recompute cascade runs once instead of once per payment. Create all the invoice receivable lines in a single `create()` call and dispatch the records back to their payment method or payment afterwards. Benchmark --------- Closing a session of 2081 invoiced orders on a copy of the customer database: - before: 558s - after: 54s opw-6458271 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#281495
Pay later receivable entries in Point of Sale are now reconciled in one grouped operation instead of repeating the process for each customer. This keeps the accounting result the same while reducing processing time and system workload during session settlement.
Original PR description
The pay later receivable lines are reconciled with one `reconcile()` call per partner, and each call filters the whole set of lines again. Reconcile them in a single `_reconcile_plan` call grouped by partner instead: the result is the same, but the recompute cascade of the ORM runs once instead of once per partner. opw-6458271 Related: https://github.com/odoo/odoo/pull/281495 Forward-Port-Of: odoo/enterprise#127415
The Live Chat settings now explain that automatic chat popups only open on larger screens. This helps teams avoid confusion when testing on phones or small screens, where visitors must tap the chat button manually.
Original PR description
The 'Open automatically' action only triggers the auto popup on larger screens (`ui.isSmall` is checked in `AutopopupService. allowAutoPopup`). On mobile/small viewports, only the chat button is shown and the visitor must tap it manually. The existing help text does not mention this, which could lead to confusion when the auto popup does not trigger during testing on mobile. Update the field's help text to explicitly state that automatic opening is limited to larger screens. opw-6459279 Forward-Port-Of: odoo/odoo#284785
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
Freezing an editable spreadsheet now records the expected data loss prevention log. This improves auditability for document spreadsheet actions and helps businesses track sensitive data handling more reliably.
Original PR description
Task: 6389096 Forward-Port-Of: odoo/enterprise#126461
This fixes an issue where syncing a recurring Outlook event could recreate the entire series after only the first occurrence was moved. Event-specific changes, such as adding an attendee to one occurrence, now stay limited to that occurrence instead of being copied to every event in the series.
Original PR description
The stored rrule of a recurrence embeds a DTSTART line based on the recurrence dtstart (the smallest start among its events). When the first occurrence is moved in Outlook, the Odoo dtstart no longer…
The stored rrule of a recurrence embeds a DTSTART line based on the recurrence dtstart (the smallest start among its events). When the first occurrence is moved in Outlook, the Odoo dtstart no longer matches that DTSTART, but the stored rrule is not recomputed at that point (it only depends on the pattern fields). On a later sync touching the seriesMaster (e.g. after adding an attendee to the moved occurrence), the recurrence values are written again and the rrule is reserialized with a DTSTART based on the moved occurrence. _write_from_microsoft() took this new rrule string as a pattern change and reapplied the recurrence: all occurrences were deleted and recreated as copies of the moved one, spreading its specific data (e.g. the newly added attendee) to the whole series. Ignore the DTSTART line when comparing the rrule before and after the write: a DTSTART-only difference does not reflect any pattern change in Outlook. An actual pattern change (FREQ, UNTIL, INTERVAL, ...) still reapplies the recurrence as before. Steps to reproduce: 1. In Outlook, create a recurring event 2. In Odoo, run the calendar sync 3. In Outlook, move the first occurrence of the recurrence (shift its start and stop time by 30 minutes) 4. In Odoo, run the sync 5. In Outlook, add an attendee to that same first occurrence 6. In Odoo, run the sync All the occurrences are deleted and recreated as copies of the first one, and the attendee ends up on every occurrence instead of one. opw-5129848 Forward-Port-Of: odoo/odoo#284447 Forward-Port-Of: odoo/odoo#269549
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
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
Changing a project's visibility no longer fails when the project folder contains shortcuts to documents. This ensures project access settings can be updated reliably while still preventing direct access changes on shortcut-only selections.
Original PR description
Changing a project's visibility fails when its documents folder contains a shortcut. The visibility change is never applied and the following error is raised: "You can not update the access of a…
Changing a project's visibility fails when its documents folder contains a shortcut. The visibility change is never applied and the following error is raised: "You can not update the access of a shortcut, update its target instead." ### Reproduction steps - Create a project and add a document to its folder. - Create another document outside the project's folder. - Create a shortcut to that document in the project's folder. - Change the project's visibility. ### Cause Changing a project's visibility updates the access rights of its folder and documents together. The shortcut access check is meant to reject operations performed only on shortcuts. However, reading `shortcut_document_id` on a recordset returns the shortcut targets found across that recordset. Therefore, the presence of a single shortcut makes the check reject the whole operation. This prevents regular documents and the project folder from having their access updated. ### Fix Only reject access updates when all records involved are shortcuts. This preserves the protection against changing shortcut access directly while allowing project access updates to include shortcuts alongside regular documents and folders. opw-6472637 Forward-Port-Of: odoo/enterprise#128756
This change reverts a recent GIF resizing update that caused slow loading and memory errors when pages displayed several GIF images. It helps keep views such as Kanban pages responsive and prevents crashes in image-heavy scenarios.
Original PR description
Revert commit d9fae40571c4f10c17fe00efc087cb25b30b85ab as it's slow on odoo.com and the call to `frame.copy()` is raising a MemoryError when loading a KanbanView with multiple gifs. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#284479
The Brazilian AvaTax sales module now includes the missing dependency needed for its sales order fields to load correctly. This prevents installation failures in specific setup scenarios, helping customers and implementers enable the module reliably.
Original PR description
When installing l10n_br_avatax_sale with --skip-auto-install, you'll get an error about the l10n_br fields listed in views/sale_order_views.xml, because these fields don't fully exist without sale_external_tax. This happens because they're defined on a mixin, which is an abstract model. Abstract models only add their fields to a model that actually lists them in `_inherit`. sale.order should list this mixin, but currently doesn't. Adding that dependency is an unstable fix, so it will be added in master (20.0, or 20.1) runbot-237866 Forward-Port-Of: odoo/enterprise#128142