Friday, March 27, 2026
17 changes · saas-18.4
Enhancements to existing features
The Spanish SII demo setup is updated to use a more reliable official test environment. This helps teams test Spanish electronic invoicing scenarios without being blocked by the previous unavailable demo environment.
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#255765 Forward-Port-Of: odoo/odoo#255377
Resolved issues and error corrections
The online shop now respects the editor setting to hide product filters when shoppers use a mobile device. This prevents customers from seeing filter options that the website manager intentionally disabled, keeping the mobile shopping experience consistent.
Original PR description
Steps to reproduce: 1) Go to the shop page 2) Open the editor and select the 'hide' option for filters 3) Switch to mobile view and click on the 'Filters' button Issue: - Filters are still displayed in mobile view even when the 'hide' option is selected in the editor. Cause: - The attribute filters template is always rendered in mobile view without checking the selected visibility option. Fix: - Add a condition to the `t-call` of the filters template so it is only rendered when an option other than 'hide' is selected. opw-5982147 Forward-Port-Of: odoo/odoo#255997
This fixes an internal test stability issue where some older Chrome versions may not create a debug log file. Odoo now handles that missing file gracefully, helping avoid unnecessary test failures without changing user-facing behavior.
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 fix prevents upgrades of the UAE localization module from failing when a user has renamed the United Arab Emirates country record. It uses a stable internal reference instead of the editable country name, making upgrades more reliable for customized databases.
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#255993The customer rating form in Project now shows only one Comment field instead of two. This reduces confusion for users reviewing customer feedback and keeps the rating record cleaner.
Original PR description
**Steps to reproduce:** - Enable the customer rating from project's setting. - Go to project > Reporting > Customer Ratings. - Open any rating record. - Observe that the 'Comment' field is displayed twice. **Issue:** - The form view contains a two different field with same string i.e feedback and publisher_comment **Fix:** - Made the publisher_comment field invisible in project's customer rating **Task-id: 5359052** Forward-Port-Of: odoo/odoo#237687
This update gives Point of Sale test refreshes more time to finish saving local browser data before the page reloads. It helps reduce false test failures and improves confidence in release validation without changing customer-facing behavior.
Original PR description
In some tests, we use refresh which will refresh the page after letting the indexedDB finish its transactions. In some cases, the transactions take more time than expected. In this commit, we increase this timeout to avoid failures that could be caused by not letting the time to the db to finish its transactions. runbot-errors: 240911, 240912 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253095
Imported XML files are no longer reused when exporting customer invoices, so any later invoice changes are included in the generated electronic document. Purchase documents keep the previous behavior, where the imported XML can still be reused because they are not expected to be edited in the same way.
Original PR description
Problem --------- Currently, when importing a move, `ubl_cii_xml_file` gets set with said XML. This XML is then re-used during the export rather that regenerate a new XML each time. This is fine for customer bills as those are not meant to be modified. This is not the case of customer invoices. Client may import an invoice XML and later update that invoice. In such a case, we want to regenerate the XML and not reuse the imported version. Solution --------- Only set `ubl_cii_xml_file` for purchase move during the import. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256052
This update corrects a test issue that could falsely report failures when servers ran in time zones ahead of UTC. It helps keep automated checks stable and ensures EDI order date validation uses a consistent date source.
Original PR description
The Issue: Before this commit, the generated EDI XML used `sale_order.create_date.date()` to populate the IssueDate node, while the test used `datetime.today().date()` to build the expected value. Since `create_date` is a UTC timestamp set by the database and `datetime.today()` returns the local system time, these diverge when the server timezone is ahead of UTC and the test runs shortly after local midnight (e.g., runbot at 01:00 CET produces UTC date Jan 11 vs local date Jan 12). The Fix: Align the test to derive its expected date from `so.create_date.date()` instead of `datetime.today().date()`, ensuring both sides use the same timezone-consistent source of truth. runbot-237841 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents translated values from being lost in temporary form data when related fields trigger recalculations. It helps ensure users working in different languages continue to see the correct translated content after onchange updates.
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#256207 Forward-Port-Of: odoo/odoo#256111
This update resolves an issue where the 'Comment' field was appearing twice on the Customer Ratings reporting form. The fix made the duplicate 'publisher_comment' field invisible, streamlining the form and improving the user experience. This ensures consistent and accurate data reporting.
Original PR description
**Steps to reproduce:** - Go to helpdesk > Reporting > Customer Ratings. - Open any rating record. - Observe that the 'Comment' field is displayed twice. **Issue:** - The form view contains a two different field with same string i.e feedback and publisher_comment **Fix:** - Made the publisher_comment field invisible in helpdesk's customer rating **Task-id: 5359052** Forward-Port-Of: odoo/enterprise#100823
This update resolves an issue where discounts weren't correctly applied in the self-order point-of-sale flow. The fix ensures that discount information is properly passed through, preventing errors and guaranteeing accurate pricing calculations. This improves the reliability of the self-order process.
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 Uruguay localization. This change aligns with how delivery guides and withholdings are handled, ensuring data consistency and accuracy for financial reporting.
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 resolves a technical issue where the AI system incorrectly identified the current user as a potential correspondent. The fix prevents this misconfiguration, ensuring accurate AI interactions and improving the reliability of the system. This change focuses on internal AI processes.
Original PR description
The fallback logic in computeCorrespondent was unintentionally allowing cases where the current user could be returned as the correspondent for AI.
This update corrects an issue where Web Studio exports were incorrectly formatting property data. The fix ensures that properties are exported in the correct XML format, improving the reliability and accuracy of exported configurations. This resolves a technical problem that could have impacted the ability to properly recreate Web Studio setups.
Original PR description
Since this commit*, properties are exported as an orm field object, while this method is meant to export the fields into xml records. This commit fixes this by converting the value before exporting it (using hidden _values). *https://github.com/odoo/odoo/commit/6f5e7aa783b336941f95c66ae70cb4ee160c00f4 Forward-Port-Of: odoo/enterprise#110336
This update resolves an issue where tax lines within the bank reconciliation widget couldn't be manually unmatched when the related tax account was set to 'reconcilable'. Previously, this prevented users from correctly reconciling transactions. Now, users can unmatch these tax lines, ensuring accurate bank reconciliation and tax reporting.
Original PR description
In the bank reconciliation widget, tax lines are protected from unreconciliation to maintain tax integrity. However, when the tax account is set as reconcileable the user may need to manually unmatch transactions. Steps to reproduce: - Open the 'Tax Paid' account and enable 'Allow Reconciliation' - Create a bill using a tax and post it - Go to the Bank Reconciliation widget - Select a statement line and match it with the tax line from the bill Issue: The line cannot be unmatched because the related button is missing opw-5871821 Forward-Port-Of: odoo/enterprise#110186
This update resolves a crash issue in tax reports when a report lacks a defined return type. The fix ensures reports automatically fall back to the company's tax periodicity, providing greater stability and reliability for financial reporting. This change addresses a previously identified bug related to date scope calculations.
Original PR description
When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid, since a return type without periodicity will anyway fallback to the the company's tax periodicity field. When there's no return type, we should simply fallback in the same way. To reproduce: - Make a Belgian company, install the CoA and localization - Manually uninstall l10n_be_reports - Try opening the tax report Another message also checked that we couldn't compute this date_scope in case there was more than one return type linked to the report, arguing they have different periodicities, so we can't infer which one to use. However, it they actually shared the same periodicity, that check failed anyway. We refine it to authorize this case, and only raise if they truly have different periodicities. opw-6022150 Forward-Port-Of: odoo/enterprise#111796
This update corrects a technical issue related to how international payment data (QR-IBANs) is processed for creditor accounts. The fix ensures that QR-IBANs are correctly categorized, aligning with industry standards and preventing potential payment rejection by banks. This improves the reliability of international payment processing.
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