Daily updates from Odoo
Thursday, June 25, 2026
15 changes · saas-19.2
Enhancements to existing features
This update reduces unnecessary error noise when checking connected devices that are not the expected type. It also makes the code more precise and easier to maintain, which helps keep logs clearer for support and operations teams.
Original PR description
We remove the stack trace from the exception reading FDM response to avoid polluting the logs when probing non FDM ports. We also now catch a more precise `IndexError` instead of `Exception` as it wasn't necessary to catch this wide. We also caught the opportunity to ruff the file.
Resolved issues and error corrections
The Mozambique demo company now uses a valid NUIT tax number. This prevents validation errors in updated standard number checks and keeps demo data working correctly.
Original PR description
Newer versions of stdnum (2.2) also test the number for MZ We did not have a valid NUIT number in the MZ demo company. Runbot error: https://runbot.odoo.com/runbot/build/114118067 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#271398 Forward-Port-Of: odoo/odoo#271299
This update resolves a technical issue preventing the Spanish E-Invoice module (l10n_es_edi_verifactu) from functioning correctly during upgrades. The fix ensures the necessary 'certificate' module is loaded first, preventing a critical error that blocked the module's operation. This ensures a smoother upgrade process and correct functionality for users utilizing the Spanish E-Invoice feature.
Original PR description
### Issue `l10n_es_edi_verifactu` builds an inheritance on `certificate.certificate` and loads that module's views/demo, but only declares `depends: ['l10n_es']`. With `certificate` not guaranteed to…
### Issue `l10n_es_edi_verifactu` builds an inheritance on `certificate.certificate` and loads that module's views/demo, but only declares `depends: ['l10n_es']`. With `certificate` not guaranteed to load first, building the registry without it already present raises: ``` TypeError: Model 'certificate.certificate' does not exist in registry. ``` ### Cause `models/certificate.py` → `_inherit = 'certificate.certificate'`; manifest `data` loads `views/certificate_certificate_views.xml` and `demo/demo_certificate.xml`. Yet `certificate` is absent from `depends`. Every sibling (`l10n_es_edi_facturae`/`sii`/`tbai`, `l10n_sa_edi`) already depends on `certificate`. Present since the module was added in `02f8d5525eb7`. ### Notes - Opened on **18.0** so it **forward-ports to 19.0** (both stable branches carry the bug). `master` already has the equivalent change via #234729 — the forward-port there should be a no-op. - Surfaced via an 18.0→19.0 OpenUpgrade migration that force-updates `verifactu` before `certificate` loads; also reproducible on a plain install where `certificate` isn't otherwise pulled in first. Forward-Port-Of: odoo/odoo#271827 Forward-Port-Of: odoo/odoo#271496
This update resolves an issue where outdated cluster bubbles remained visible on the company map after zooming or panning. The fix corrects a technical error in how the map's cluster icons were managed, ensuring that old icons are properly removed when the map updates. This improves the visual clarity and accuracy of the map for users.
Original PR description
Steps to reproduce: =================== 1. Install website_customer, set a Google Maps API key and publish a few companies with coordinates 2. Open /customers 3. Open the map and zoom in a few times…
Steps to reproduce: =================== 1. Install website_customer, set a Google Maps API key and publish a few companies with coordinates 2. Open /customers 3. Open the map and zoom in a few times => stale blue cluster bubbles remain on the map Cause: ====== On the partner map, zooming or panning left old cluster bubbles behind: the blue count icons piled up and never disappeared, even at the closest zoom level. `ClusterIcon` is meant to be a google.maps.OverlayView. The bundled `markerclusterer.js` wires that up by copying every enumerable https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L213-L221 OverlayView.prototype member onto ClusterIcon.prototype. Google Maps now ships its own OverlayView.prototype.remove, and that copy overwrites ClusterIcon's own `remove()` with it, As a result, when a cluster icon is removed, `ClusterIcon.remove()` is never executed. Consequently, `ClusterIcon.prototype.onRemove()` is not triggered, the cluster icon's DOM element is never detached from the map, https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L1167 and stale cluster bubbles accumulate after every redraw, zoom, or pan operation. Solution: ========= Inherit from OverlayView through the prototype chain instead of copying it, so ClusterIcon's own remove() is kept and actually detaches the icon. opw-6128531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270733
This update ensures the Clickall tool, used for automated accounting dashboard testing, correctly handles requests to the new Odoo Fin v2 favorite institutions endpoint. By extending the existing request mock, we maintain isolation from production servers and prevent potential issues during testing, ensuring reliable automated test results.
Original PR description
This commit follows up on [1] by extending the Odoo Fin request mock to cover the new version 2 (v2) favorite institutions endpoint. Previously, a mock was introduced to prevent the Clickall tool from making real external HTTP requests to `production.odoofin.com` when displaying the accounting dashboard. This update ensures that the newly introduced v2 URL is also safely intercepted, keeping the automated tests fully isolated from production servers. runbot-234936 [1] : https://github.com/odoo/odoo/commit/c6451015f1b01c3e1defe4a576989fd4bfdf2cdb Forward-Port-Of: odoo/odoo#271804
This update resolves an issue where event titles were sometimes saved as blank ('(no title)') when created quickly through the calendar. The fix ensures that all event data, including the title, is saved correctly, regardless of how the event was created. This improves the user experience and prevents data inconsistencies.
Original PR description
When creating an event using the quick create form from the calendar view if the user saves the record while the title is still being edited (using alt+c) the record will be saved with the default title: "(no title)" The code currently relies on the record data being up to date by the time onRecordSave is reached. However in the case of a text field, it is only saved when blurred. While there is a mechanism to blur the field when saving using a hotkey, it is completely asynchronous from the save logic of the form. To ensure all fields have comitted their data at save time, the framework has a mechanism to "request changes" which notifies all fields to update the record with their latest value and waits for them to do so. We can simply reuse this mechanism to ensure the data is up to date at recordSave time already, as we don't expect fields to have any changes after it. task-6321702 Forward-Port-Of: odoo/odoo#271473
This update fixes an issue where the composer in Odoo (used for creating emails) wasn't correctly handling text editing after inserting mentions. Specifically, it added a small character (a zero-width no-break space) to ensure the cursor moved to the end of the line, improving the user experience. This ensures users can accurately edit and format their emails.
Original PR description
### Purpose of this PR: - Inserting a mention in the composer results in a paragraph ending with a bare `<a>` element and no trailing text node. This causes the browser to mishandle the End key, moving the caret to the start of the next paragraph instead of the end of the current line. - Fix by appending a \uFEFF (zero-width no-break space) text node. task-6295924 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271160 Forward-Port-Of: odoo/odoo#269699
This update resolves an issue where a key feature of our website tours was intermittently failing. The fix ensures the tour correctly identifies the target element before the drag-and-drop action, making the tour more reliable and consistent for users. This improves the overall user experience.
Original PR description
The tour `conditional_visibility_4` has non-deterministic failure, that appears to be caused by the `drag_and_drop` step dragging the element that was the target before the click of the previous step. This commit adds a step to ensure the target is the expected element before the "drag" step starts. runbot-242425
This update resolves a bug where the 'Suggest Forecasted Demand' button disappeared when the 'Forecasted Stock' row was hidden in the Master Production Schedule. This ensures the button is always visible, allowing users to accurately adjust forecasted demand. This fix improves the usability of the planning module.
Original PR description
Steps to reproduce:
1. Install Manufacturing.
2. Enable 'Master Production Schedule' in the Settings.
3. Go to [Manufacturing -> Planning -> Master Production Schedule].
4. Ensure 'Demand Forecast' and 'Forecasted Stock' rows are enabled from the dropdown.
5. Observe the edit pencil button next to 'Forecasted Demand' is visible.
6. Hide 'Forecasted Stock' using the rows filter dropdown.
Issue:
The edit pencil button ("Suggest Forecasted Demand") next to the 'Forecasted Demand' row disappears when the 'Forecasted Stock' row is hidden.
Expected behavior:
The edit pencil visibility should not be affected by the 'Forecasted Stock' row.
opw-6240596
Forward-Port-Of: odoo/enterprise#120208This update fixes an issue where quality alerts weren't created when receiving inbound emails without a company assigned. The fix ensures that a default company ID is used, preventing errors and guaranteeing that all email-based quality alerts are properly recorded. This improves the reliability of our quality tracking system.
Original PR description
Steps to reproduce 1. Install quality 2. Create an incoming email server 3. Go to Quality > Configuration > Quality Teams > Team > add alias email 4. Do not fill the company field 5. Send email to this alias 6. Fetch emails from incoming email server Issue: - Record is not created in the quality alert Root cause: - For the Quality alert model, the field `company_id` is required, but while we fetch emails We haven't set the `company_id` on the quality alert team, resulting in trying to insert a null value on the quality alert model. Solution: - Give a default value to company_id. - Raise a validation error on not having a company_id - Update alias default values on changing company_id opw-5917791 Forward-Port-Of: odoo/enterprise#118516 Forward-Port-Of: odoo/enterprise#109947
This update ensures that all tax unit members, not just the main company, have read access to tax return checks. This allows for quicker resolution of issues related to failing checks, improving overall operational efficiency and reducing potential delays.
Original PR description
Before this commit: Tax Unit Members other than main company have read access to tax returns but don't have read access to tax return checks. After this commit: Tax Unit members other than main company are given read access to tax return checks also, so they can fix checks failing because of them. task-5951364 Forward-Port-Of: odoo/enterprise#113118
This update fixes a display issue in the Helpdesk module where ticket labels in list and form views didn't match the labels shown in the Kanban view. The fix removes outdated label fields from the views, ensuring all ticket views now accurately reflect the selected state values. This improves consistency and clarity for users.
Original PR description
Steps to reproduce: ------------------------ 1. Install Helpdesk 2. Go to All Tickets and check the kanban state selection value 3. Go to Settings > Field Selection and search for kanban_state in…
Steps to reproduce:
------------------------
1. Install Helpdesk
2. Go to All Tickets and check the kanban state selection value
3. Go to Settings > Field Selection and search for kanban_state in `helpdesk.ticket` model
4. Change one of the state selection values (e.g., "Ready" to "Testing Ready")
5. Go back and check the state selection value in list and form views
Current behavior:
-----------------------
Kanban view correctly shows the updated label (e.g., "Testing Ready"),
but list and form views still display the old default value (e.g., "Ready").
Root cause:
---------------
The [state_selection](https://github.com/odoo/odoo/blob/c09cefdb0ed68b1b7367b77b18a5ee5d66c94900/addons/web/static/src/views/fields/state_selection/state_selection_field.js#L57-L65) widget uses `legend_${state}` field values when available.
Since list and form views included these legend fields, the widget resolved labels from them
instead of the actual selection values, causing inconsistent display.
Fix:
-----
Remove `legend_normal`, `legend_blocked`, and `legend_done` fields from the list and form views,
So the widget falls back to the real selection labels, consistent with how the kanban view behaves.
Reference commit: https://github.com/odoo/enterprise/commit/65f3b88254e3a66e2c5dcb5142d30f6b1996d999
opw-6238765
Forward-Port-Of: odoo/enterprise#119707This update fixes a display issue where the Incoterm (shipping term) wasn't showing on purchase quotation reports. After a recent code update, the fix ensures that this important information is now correctly presented, improving clarity for purchasing teams. This ensures accurate reporting and better understanding of shipping costs.
Original PR description
After a refactor the incoterm and location didn't show on the purchase quotation Task-id: 6206523
This update fixes an issue where custom inline shadows weren't correctly recognized by the HTML builder, leading to incorrect shadow displays. Now, elements with inline shadows are properly detected, and cleaning custom shadows also removes Bootstrap shadow classes. This ensures consistent and accurate shadow rendering across Odoo.
Original PR description
Before this PR, , since [1], elements with an inline `box-shadow` and no custom shadow class were not detected as custom shadows by the builder option. This could make existing snippets show the wrong shadow state. After this PR, elements with an inline `box-shadow` are treated as custom shadows by the builder option, and cleaning the custom shadow also removes Bootstrap shadow classes. [1]: https://github.com/odoo/odoo/commit/55890082db7879bef3a976c84ab336bdacf76818 task-6251151
This update resolves an issue where the CoA reload process could inadvertently create duplicate reports. The CoA framework is now responsible for managing existing records, ensuring data integrity and preventing redundant report generation. This change improves system efficiency and accuracy.
Original PR description
It is the burden of the CoA framework to check for that. See community commit for more information. Forward-Port-Of: odoo/enterprise#121643