Friday, March 27, 2026
18 changes · saas-18.2
Enhancements to existing features
Updates the Spanish SII demo environment to use a working AEAT test setup instead of the unreliable Gipuzkoa test environment. This helps demo and testing workflows run more reliably without extra manual setup.
Original PR description
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 Forward-Port-Of: odoo/odoo#255377
Resolved issues and error corrections
Users editing report source code can now save an empty XML report without triggering a technical error. This prevents an avoidable crash in Studio report editing and keeps the save flow stable when report content is blank.
Original PR description
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External…
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External > Type Text in report - Save > Edit Sources > Remove full XML > Save Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)` This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error. In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow `view.arch` to be empty. As a result, this error is no longer handled by the constraint. This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available. [1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367 [2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377 [3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f sentry-6288795955 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 Forward-Port-Of: odoo/odoo#255316
Creating a link from selected content that includes both text and an icon now keeps the icon in place. This prevents visual content from disappearing in the HTML editor and makes link creation behave as users expect.
Original PR description
Problem: When a selection contains both text and an icon, creating a link removes the icon from the content. Cause: Icons should be treated the same way as images during link creation. If an icon is present in the selection but not handled like an image, it gets removed when the link is applied. Solution: Handle icons in the same way as images when processing selections for link creation, ensuring they are preserved. Steps to reproduce: - Add text "abc" followed by an icon. - Select both the text and the icon. - Create a link. - Observe that the icon is removed and only the text remains. opw-6066195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Restarted chatbot conversations now only add messages from the new session to any created ticket or lead. This keeps customer records cleaner and prevents outdated chat history from being mixed into new follow-ups.
Original PR description
Before this commit: When a chatbot conversation is restarted and the script creates a new ticket/lead, the description also includes messages from the previous session. After this commit: Only the messages sent after the chatbot conversation is restarted are included in the ticket/lead description. Task-5118966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253566
This fix prevents translated values on related fields from being lost from the system cache during onchange updates. It helps ensure computed fields continue using the correct language-specific values, improving consistency for multilingual users.
Original PR description
when related translated field (field_x) is changed when onchange, if another computed fields which depends on the field_x is recomputed but using another language value of the field_x. The orm should keep the existing translations in the cache but not drop them. 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 Forward-Port-Of: odoo/odoo#256111
Automated tests now prepare a required messaging asset in advance instead of rebuilding it repeatedly during test runs. This reduces unnecessary test processing and helps make validation of changes more efficient without affecting end users.
Original PR description
This commit sets the `bus.websocket_worker_assets` bundle to be pregenerated while running tests to avoid rebuilding it at runtime (i.e. +900 times with a db "all"). Forward-Port-Of: odoo/odoo#255843
The live chat test setup now prepares a required asset bundle in advance instead of rebuilding it repeatedly during test runs. This reduces unnecessary processing and helps make automated testing faster and more reliable, without changing the customer-facing live chat experience.
Original PR description
This commit sets the `im_livechat.assets_embed_external` bundle to be pregenerated while running tests to avoid rebuilding it at runtime (i.e. +280 times with a db "all"). Forward-Port-Of: odoo/odoo#255847
Users now receive a specific message when they try to create a property field before setting the required parent field. This avoids confusing access-rights warnings and helps users understand what information they need to provide first.
Original PR description
Issue: ------------------------------------------ - When using property fields (e.g., products since 18.1 where categories are optional), users trying to add a property field without a parent…
Issue: ------------------------------------------ - When using property fields (e.g., products since 18.1 where categories are optional), users trying to add a property field without a parent document receive a generic warning: "You need edit access on the parent document to update these property fields". - This message is misleading and does not explain the actual dependency. How to reproduce: ------------------------------------------ 1. Create or edit a record (e.g., product) without setting its parent (e.g., category). 2. Try to add a property field. Cause of the issue: ------------------------------------------ - In `checkDefinitionWriteAccess`, when `definitionRecordId` is missing, the method returns `false`, triggering a generic access-rights warning. Solution: ------------------------------------------ - Added a check at the beginning of `onPropertyCreate` verify if `definitionRecordId` exists. - If missing, following error is raised using the parent field label: "You must set the '%s' field to create a property field." task-4589393
This fix makes the UAE localization data use a stable country reference instead of relying on the country name. Businesses that rename or translate “United Arab Emirates” can now upgrade the UAE localization module without the process failing.
Original PR description
### Steps to reproduce ------------------ - Install `l10n_ae` module. - Go to *Settings → Countries* and rename the country "United Arab Emirates" (e.g. change it to "UAE"). - Upgrade the `l10n_ae`…
### Steps to reproduce
------------------
- Install `l10n_ae` module.
- Go to *Settings → Countries* and rename the country "United Arab Emirates" (e.g. change it to "UAE").
- Upgrade the `l10n_ae` module.
### Issue
-----
The file `l10n_ae/data/res.bank.csv` references the country using its name ("United Arab Emirates"). During the module upgrade, the CSV import tries to resolve the country relation using the country name. If the country name has been modified by the user (for example to "UAE"), the lookup fails and the module upgrade crashes with:
```python3
No matching record found for name 'United Arab Emirates' in field 'Country'
```
### Root Cause
----------
Using translatable/display names in CSV data is unreliable, as these values can be customized or translated by users.
### Fix
---
Replace the country name reference with the stable XMLID `base.ae` in `res.bank.csv`.
Using XMLIDs ensures consistent resolution regardless of name changes or translations.
opw-6015302
upg-3950261
tbg-2492
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
Forward-Port-Of: odoo/odoo#255993This fix prevents automated browser tests from failing when older Chrome versions do not create a debug log file. It makes the test infrastructure more reliable across different Chrome environments without changing business features or user workflows.
Original PR description
Follow up to #255054 [Apparently][] on old versions of chrome `chrome_debug.log` may not exist if the verbosity is not at least 1 (or chrome otherwise has had things to write to the log). Thus handle the possibility of the file being missing instead of assuming it's present just because we've told chrome to generate one. [Apparently]: https://github.com/odoo/odoo/pull/255054#pullrequestreview-4001460518 Forward-Port-Of: odoo/odoo#255846 Forward-Port-Of: odoo/odoo#255736
This fixes an issue where clicking outside the command palette could make the HTML editor jump back to the top. The editor now keeps the user's cursor position and selection, reducing disruption while editing content.
Original PR description
Before this commit: the editable area scrolls to the top when the command palette is closed by clicking the gray zone After this commit: we override the focus function of the editable and use focusEditable instead, which keeps the selection. Note it's a succession fix of https://github.com/odoo/odoo/pull/250624 and both of them are a workaround without touching the ui_service and command palette. Also added super.destroy() in the previous fix till 18.4. task-6034339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253638
This update resolves an issue where saving a report with an empty XML format in the Web Studio tool would generate an error. The fix prevents the system from attempting to process empty XML data, ensuring a smoother user experience when creating reports.
Original PR description
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External…
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External > Type Text in report - Save > Edit Sources > Remove full XML > Save Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)` This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error. In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow `view.arch` to be empty. As a result, this error is no longer handled by the constraint. This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available. [1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367 [2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377 [3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f sentry-6288795955 Forward-Port-Of: odoo/enterprise#88613
This update fixes a display issue in the SEPA payment file generation process. Previously, the UI incorrectly showed an empty field for the PAIN 09 version, even when a valid value existed in the database. This change ensures the correct PAIN 09 version is consistently displayed, improving data accuracy for financial transactions.
Original PR description
https://github.com/odoo/enterprise/commit/80f9f966d7db793ae82e65c76514323cb10e34ab tried to fix the issue, but assumed the field would be returned empty by the ORM when the value was inconsistent with the db. It's not true: it returns the database value ; only the UI shows the field as empty. Forward-Port-Of: odoo/enterprise#112141
This update resolves an issue where only administrators could delete work entry types within the payroll module. Now, users with SUPERUSER permissions can also delete these types, streamlining payroll administration. This change improves operational efficiency and reduces reliance on specific user roles.
Original PR description
Forward-Port-Of: odoo/enterprise#111967
This update resolves an issue where the self-order process in the German POS module incorrectly handled discounts. The fix ensures that discount information is properly passed, preventing errors and ensuring accurate order totals. This improves the reliability of the self-order functionality.
Original PR description
In the pos self-order flow, `_check_pos_order_lines` does not forward the `discount` field when sanitizing order lines. This caused `_merge_order_lines` to raise a `KeyError` when using `itemgetter('discount')` on lines that lack the key.
opw-6052719
Forward-Port-Of: odoo/enterprise#111591This update prevents the system from incorrectly syncing ‘e-Cobranza’ documents (collection notes) as vendor bills in the Uruguayan localization. This change aligns with how other related documents like ‘e-Remito’ and ‘e-Resguardos’ are handled, ensuring data consistency and accuracy.
Original PR description
This pull request improves the synchronization process of vendor bills within the Uruguayan localization (`l10n_uy_edi`). Currently, the system might fetch documents that are not technically bills during synchronization. With this change, the system will explicitly avoid synchronizing `e-Cobranza` (Collection notes or Receipts) documents as vendor bills. Reasoning: `e-Cobranza` documents function conceptually more like payment receipts rather than actual vendor bills. Pulling them into the system as bills creates inconsistencies. This update aligns the handling of `e-Cobranza` with the existing behavior for `e-Remito` (Delivery Guides) and `e-Resguardos` (Withholdings), which are also appropriately excluded from bill synchronization. **Related Tasks** LATAM Task: 1367 ADHOC Task: 58906 Forward-Port-Of: odoo/enterprise#100549
This update fixes a warning displayed in the tax report when vendor bills have expense lines with different vehicle assignments. The fix allows for flexibility in handling tax lines across mixed vehicle and non-vehicle expense lines, ensuring accurate reporting. This improves the reliability of the tax reporting process.
Original PR description
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other…
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other without a vehicle. * Confirm the vendor bill. * Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report. **Observed behavior:** * The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.' **Cause:** * The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`. * When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`. * The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency. **Fix:** * Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set. * If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines. opw-5956645 Forward-Port-Of: odoo/enterprise#110616
This update corrects a technical error related to how QR-IBANs are processed in international payments. Specifically, it ensures QR-IBANs are correctly placed within the account structure as required by banking standards. This resolves a potential issue that could have caused payment failures.
Original PR description
https://github.com/odoo/enterprise/pull/112273 introduced a bug, where qr-iban are put inside Othr node instead of IBAN node for the Creditor account. According to documentation, for the debtor account, you should not use a qr-iban, and if you do, it should be put inside the Othr node (even if in this case, the transfer will probably be refused by the bank). Forward-Port-Of: odoo/enterprise#112301