Friday, June 5, 2026
22 changes · 19.0
Enhancements to existing features
Updated the Spanish (Latin America) wording for “Effectively Paid” in the Mexican localization so it correctly describes a payment status rather than sounding like a cash payment. This improves clarity and alignment with Mexican accounting terminology, with no functional impact.
Original PR description
## Merge method squash --- ## Summary The translation for `'Effectively Paid'` in `addons/l10n_mx/i18n/es_419.po` was rendered as `'Pago efectivo'` (a noun phrase), which is grammatically incorrect…
## Merge method squash --- ## Summary The translation for `'Effectively Paid'` in `addons/l10n_mx/i18n/es_419.po` was rendered as `'Pago efectivo'` (a noun phrase), which is grammatically incorrect in this context. In the Mexican chart of accounts (`template_mx.py`), `'Effectively Paid'` describes a **payment state/condition** — it should be expressed as an adjectival participial phrase in Spanish. ## Change | `msgid` | Before | After | |---|---|---| | `Effectively Paid` | `Pago efectivo` | `Efectivamente pagado` | ## Why this matters - `'Pago efectivo'` translates back to English as _'Cash payment'_ or _'Effective payment'_ — a noun, not a state descriptor. - `'Efectivamente pagado'` correctly means _'Effectively paid'_ — matching the semantic intent of the original string as a participial/adjectival phrase used to label a journal account. - This aligns with standard Mexican accounting terminology where the concept of "pago efectivamente cobrado/pagado" is well established in fiscal contexts (SAT, CFDI). ## Testing No functional change — translation string only. Verified against `l10n_mx.pot` template.
Resolved issues and error corrections
This fix allows companies to send Peppol e-invoices to partners using the 0225 identifier without requiring the French PDP module. It removes an unnecessary setup blocker, including for French trial companies installing hair salon demo data.
Original PR description
Previously we blocked the 0225 peppol_eas when `l10n_fr_pdp` is not installed. But you should still be able to send to 0225 partners with just peppol. Since the PDP module is auto installed with the French localization and we block the 0225 EAS server side on the peppol (non-PDP) server it should be fine to just allow it for everyone. It also caused an issue when installing the demo data for the `hair_salon` industry in a French company on trial. opw-6268629 Forward-Port-Of: odoo/odoo#268146 Forward-Port-Of: odoo/odoo#267993
This fixes an issue where changing text color on mobile could close the color picker without applying the chosen color. Users can now reliably set colors while typing in the HTML editor, reducing formatting frustration.
Original PR description
Steps to Reproduce: - Apply color on a collapsed selection in mobile - Type some text - Change color from the color picker Description of the issue: - The color picker closes, but the selected color is not applied. Cause: - The color was being applied correctly, but the selection was positioned at offset 0 of the newly created font node. As a result, the browser normalized the selection back to the previous font node, making it appear as though the color was not applied. Solution: - When applying color on a collapsed selection, set the selection offset to 1 instead of 0. This prevents browser normalization and keeps the cursor inside the newly created font tag, ensuring the color is applied correctly. task-6201171 Forward-Port-Of: odoo/odoo#267807 Forward-Port-Of: odoo/odoo#265438
This fixes an intermittent issue in automated invoice testing where a selected product could be checked before it was fully added. The added wait makes the test flow more reliable and helps prevent false failures in invoice-related checks.
Original PR description
When a product is selected from the kanban view, the tour sometimes returns to the invoice form before the product is fully added. As a result, the invoice line is not created and the `.o_field_product_label_section_and_note_cell` element is missing from the table, causing the next tour step to fail. Add a short delay after selecting a product to ensure it is fully added to the invoice before proceeding with the following steps. runbot-238400 Forward-Port-Of: odoo/odoo#261295
This fix prevents users from selecting property fields in the field selector when that option should be disabled. It helps avoid incorrect selections and supports more reliable configuration behavior in the web interface.
Original PR description
- Backporting this [commit], for adding the `allow_properties` option to `field_selector` widget in `saas-18.2` for using the functionality in linked enterprise commit. - Also, added a test for `allow_properties` option. - For forward ports, only the test will be merged, as `allow_properties` is already included in the original commit. [commit]: https://github.com/odoo/odoo/pull/215767/changes/7cd18c07b5e008bff072d10375c908eb77434fde sentry-7378769090 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257833
The website builder no longer offers column layout options in areas where changes cannot be saved. This prevents users from creating footer or page edits that appear editable but are lost afterward.
Original PR description
When using the website builder, the tool in the powerbox to create columns is available, even when the node modified to create the columns is not `contenteditable`. This commit adds a condition for the availability of "columnize" tools: when there is no existing columns, check if the closest block ancestor (which will be replaced by the created node containing columns) is in a content editable node. Steps to reproduce: - Open website builder - Click in "Copyright" at the bottom of the footer - Type `/column` - Select "2 columns" in the powerbox - Bug: the created columns can be edited but will not be saved task-6247071 Forward-Port-Of: odoo/odoo#266420
Spreadsheet accounting formulas now convert company IDs from cell text into numbers before sending them for calculation. This prevents errors when users reference a company ID stored as text, while still allowing no company filter when the value is empty.
Original PR description
Current behavior before PR: - The `ODOO.CREDIT`, `ODOO.DEBIT`, and `ODOO.BALANCE` formulas passed `companyId.value` directly to the server without converting it to a number. - If a user passed company_id as a string (e.g., '1' from a cell), it was sent to the server as a string, causing a server error. Desired behavior after PR is merged: - `companyId` is converted using toNumber() before being passed to the getter and the server, so '1' becomes 1. - null is preserved as-is (no company filter) while any non-null value is safely cast to an integer. Task: [6240005](https://www.odoo.com/odoo/project/2328/tasks/6240005) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268187 Forward-Port-Of: odoo/odoo#266009
This fix ensures French PDP reporting flow forms can be created even when reporting period dates are not yet filled in. It prevents crashes during early form setup, improving reliability for users working with new or incomplete PDP records.
Original PR description
PDP reporting flows compute their period status from the due period dates. On a new or incomplete flow record, those dates can still be empty during form/onchange initialization. The compute then tried to compare today's date with `False`, which could crash generic form creation. This patch makes the compute handle missing period dates before doing date comparisons. runbot.build.error-939459 Forward-Port-Of: odoo/odoo#268002
Fixes the label and sign handling for a section in German localization reporting. This ensures revenue amounts from credit notes are shown correctly and the report is easier to interpret for compliance and review.
Original PR description
title of the B section is wrong. 2 lines need to be multiplied by -1 because they come from credit note but must be reported positively since they are revenue. Source https://www.odoo.com/odoo/documents/tPsLeM-TT--tTeztKJYzmAo4ae27b opw-6204994
This fixes an issue where confirming a real-cost delivery could fail if the related sales order was locked. Delivery validation can now update the shipping line with the actual carrier cost while normal manual edits to locked orders remain blocked.
Original PR description
Sale module has setting `Lock Confirmed Sales`, which particularly doesn't allow order line modification on a confirmed order. However, when a delivery carrier is set up with Invoicing Policy = Real cost, validating the picking pushes the actual carrier price onto the delivery line, writing `price_unit` and `name`. On a locked SO this raises a UserError. Fix it by excluding the delivery line's `price_unit` and `name` from the protected fields, only when the write originates from `_add_delivery_cost_to_so`. The code path is identified by the context `allow_delivery_cost_update`, so a regular UI edit of those fields on a locked SO is still blocked. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266511 Forward-Port-Of: odoo/odoo#265721
This update corrects an internal naming inconsistency in the Mexico localization bank view setup. It helps keep the system easier to maintain and aligned with current Odoo naming standards, with no expected change for end users.
Original PR description
## Merge method squash --- ## Problem In `addons/l10n_mx/views/res_bank_view.xml`, the third `<record>` has an inconsistency between its external `id` attribute and its `name` field: ```xml <!--…
## Merge method
squash
---
## Problem
In `addons/l10n_mx/views/res_bank_view.xml`, the third `<record>` has an inconsistency between its external `id` attribute and its `name` field:
```xml
<!-- Before: id uses 'tree', name uses 'list' -->
<record model="ir.ui.view" id="view_partner_bank_tree_l10n_mx_edi_bank">
<field name="name">view.partner.bank.list.mx.inherit</field>
...
</record>
```
This inconsistency was introduced when Odoo migrated from the `tree` to `list` naming convention (starting v17), but only the `name` field was updated while the external `id` was left with the old `tree` terminology.
## Fix
```xml
<!-- After: both id and name consistently use 'list' -->
<record model="ir.ui.view" id="view_partner_bank_list_l10n_mx_edi_bank">
<field name="name">view.partner.bank.list.mx.inherit</field>
...
</record>
```
## Impact
- No functional change — the `inherit_id` still correctly references `base.view_partner_bank_tree`
- Aligns the external ID with current Odoo 17+ naming conventions (`list` instead of `tree`)
- Eliminates the confusing mismatch between `id` and `name` in the same record
- Consistent with other list view IDs across Odoo 19.0 codebase
## Files changed
- `addons/l10n_mx/views/res_bank_view.xml`Country flags on the Website Visitors page now keep a consistent size regardless of whether Live Chat is installed. Images using the image URL widget also no longer disappear when their size is adjusted through Studio, improving reliability for users customizing views.
Original PR description
The website.visitor.view.kanban view uses the o_country_flag class which is not defined anywhere besides livechat_channel_info_list.scss. This causes unintended behavior where the flag size for the kanban view on ' Website > Reporting > Visitors ' changes when installing the livechat app. Additionally, the image_url_field.js file does not address cases when height/width are not set. This results in the flags (or any other image using 'widget="image_url"' disappearing (being set to a 'width: 0px') whenever their Size is set via Studio. This change makes it so that the flags don't disappear when altered in Studio (but does not make them actually respond to size changes) Related tickets: opw-5962151, opw-5995004
This update fixes a minor issue in the Odoo Enterprise spreadsheet edition. A recent change in the underlying spreadsheet library required updating the names of properties used to define cell corners. This ensures the spreadsheet functionality continues to work correctly and avoids potential display problems.
Original PR description
Since https://github.com/odoo/o-spreadsheet/pull/6063, the props name for cellCorner have been changed to use kebab-case. Forward-Port-Of: odoo/enterprise#119329
This update adds a dependency on the 'account_accountant' module to the 'account_iso20022' module. Previously, the module could function without it, but this change guarantees the necessary view components are always available, preventing potential issues during upgrades or usage.
Original PR description
In #93625, a view was added to this module which inherits from a view defined in `account_accountant`. Although `account_accountant` is installed automatically in enterprise if `account` is installed, which is also an indirect dependency of `account_iso20022`, it's not a direct dependency of `account_iso20022`. Therefore, `account_accountant` could be uninstalled by the user without affecting `account_iso20022`. This could lead to issues when upgrading or using the module. This commit adds `account_accountant` to the dependencies, to make sure that the inherited view is always available. tbg-2491
This update fixes a bug in the bank transaction creation process within the Odoo Enterprise system. When an error occurs during transaction creation, the system now correctly closes the quick create window and displays the error, preventing further issues. This ensures a smoother user experience and prevents data inconsistencies.
Original PR description
**Problem:** When an error is thrown upon creating a bank transaction in the kanban view, a traceback occurs due to trying to access the quickCreateState which does not exist in this context (`this` = BankRecQuickCreateController). **Steps to Reproduce:** - Force the suspense account of the bank journal to be False - Go to bank transactions of that journal in kanban view and try to create a new transaction -> Traceback **Solution:** The expected behavior is for the quick create to be closed, then throw the error. Therefore, onCancel() can be called before throwing the error. opw-6186901
This update resolves an issue where order data wasn't being synchronized correctly from Point of Sale systems. The fix ensures that the system accurately reflects invoices as 'done' rather than 'invoiced', leading to more reliable data flow. A minor typo was also corrected for improved stability.
Original PR description
In this commit: - Update `read_pos_data` to check `done` state for invoicing instead of `invoiced` state - Load `account.move` model instead of `account_move` (fix typo) Task-5887318 Forward-Port-Of: odoo/enterprise#119317 Forward-Port-Of: odoo/enterprise#105839
This update fixes an issue where the General Ledger and Balance Sheet reports were exporting all accounts instead of the selected one when changing date filters. The fix removes unnecessary filtering logic that was introduced previously, ensuring the report accurately reflects the user's chosen account.
Original PR description
Steps: - Open Balance Sheet report and unfold lines - Open the General Ledger from a line with an account - On GL report, change date filter - Export XLSX report -> We export all accounts instead of the one selected in the search bar Cause: Since f8dceec74e44ffe4aef67655be8811c96da91eba we filter out the filter if a default account is defined in the context which is the case in the `caret_option_open_general_ledger` method Fix: Remove the filtering as the behavior that was fixed by the mentioned commit does not happen anymore. opw-6234427 Forward-Port-Of: odoo/enterprise#119156
This update prevents Odoo from crashing when the Barcode Lookup API returns a broken image URL. Previously, an invalid URL would cause an error. Now, the system safely ignores these errors, ensuring the product picture retrieval process continues without interruption.
Original PR description
[FIX] product_barcodelookup: avoid crash on invalid image URLs **Steps to Reproduce:** - Install Sales module. - Configure a valid Barcode Lookup API key. - Create a product without an image. - Set a…
[FIX] product_barcodelookup: avoid crash on invalid image URLs
**Steps to Reproduce:**
- Install Sales module.
- Configure a valid Barcode Lookup API key.
- Create a product without an image.
- Set a barcode whose returned image URL is broken or returns HTTP 404
(e.g. `8426904171073`).
- Select the product and trigger the server action:
`Action -> Get Pictures from Barcode Lookup`
Issue:
**During image fetching:**
- Barcode Lookup API successfully returns product data and image URLs.
- `_get_image_from_url()` attempts to download the image.
- The image URL responds with HTTP 404.
- `barcode_lookup_request()` returns a dict for non-200 responses.
- `_get_image_from_url()` assumes the response is always a `requests.Response`
object and directly accesses: `response.status_code`
- This causes: `AttributeError: 'dict' object has no attribute 'status_code'`
**Root Cause:**
- `barcode_lookup_request()` returns inconsistent response types:
- `requests.Response` for successful requests
- `dict` for failed requests
- _get_image_from_url() does not handle the dict response before accessing
response attributes.
**Solution:**
- Make barcode_lookup_request() always return a One Response
object.
- Move the response validation to the callers instead of returning custom
dict objects.
**Result:**
- No RPC crash when image URLs are invalid or return 404.
- Broken image URLs are safely ignored.
**OPW-6200749**
Forward-Port-Of: odoo/enterprise#116925This update resolves an issue where users attempting to access archived documents through specific methods (like widgets or direct URLs) would incorrectly display a 'not found' message. This fix ensures that archived documents are correctly handled and accessible, improving the user experience. It's a follow-up to previous improvements related to document management.
Original PR description
When a user tries to access an archived document via * a many2one widget * `/odoo/documents.document/<id>` * a discuss notification they end up in "All" with a toast specifying that the document was not found. Follow-up of Task-6068437 (follow up of Task-5386466). Task-6214488 Forward-Port-Of: odoo/enterprise#119302 Forward-Port-Of: odoo/enterprise#117229
This update fixes an issue where the ICP export generated inconsistent XML reports by using values from multiple company contexts. The change ensures a single, reliable company context is used for identifier values, improving the accuracy and clarity of the exported data. This enhances the reliability of financial reporting.
Original PR description
Description of the issue this commit addresses: The ICP export could mix values from different company contexts. In some cases, the main identifier and the fiscal entity division value did not come from the same source, which could create confusing or inconsistent XML output. --- Desired behavior after this commit is merged: This commit makes the ICP export use one consistent company context for identifier values, reuses precomputed values when available, and avoids overwriting them with unrelated defaults. --- task-6065382 Forward-Port-Of: odoo/enterprise#119282 Forward-Port-Of: odoo/enterprise#112995
This update resolves an issue where users were blocked from uploading documents to requests linked to records they didn't have full access to. By adding a temporary 'sudo' permission during the upload process, users can now successfully attach documents, improving workflow efficiency. This ensures requests can be properly documented regardless of user access levels.
Original PR description
Issue: Users are currently blocked from uploading requested documents if the request is linked to a record they do not have access to (e.g., User A links Record X to a request assigned to User B, but User B lacks read/write access to Record X). The system throws an error because the user cannot create an attachment for that record. Fix: Add .sudo() on the attachment creation process. task-6107099 Forward-Port-Of: odoo/enterprise#113698
This update fixes a limitation in how properties are exported from records when using Odoo's spreadsheet edition. Previously, sub-properties weren't supported. Now, support is added, but to maintain consistency with older versions, sub-properties are filtered out for the spreadsheet edition until version 19.2.
Original PR description
* = [documents_spreadsheet] When exporting properties from records in the web kanban and list views, sub-properties created within a record were previously not supported. Support for exporting these sub-properties has now been added. However, in spreadsheet this should only be enabled from saas-19.2 onwards (where it is already available). To keep the behavior aligned with the usual flow on earlier versions, this filters out the sub-properties exported from the record in `spreadsheet_edition`. community: https://github.com/odoo/odoo/pull/264267 task-6123524