Daily updates from Odoo
Friday, November 7, 2025
218 changes
16 changes
Enhancements to existing features
This update speeds up stock move validation by avoiding repeated recalculation of the same location hierarchy data for each move line. As a result, large transfers complete significantly faster, reducing waiting time for users handling inventory operations.
Original PR description
Previously when validating a movement with a location that is used in a rule, move_dest_ids was set which led to it going to check the putaway strategy. The bottleneck was the computation of the computed field child_internal_location_ids which is the same across all smls. This PR utilizes the fact that the smls in the same stock_move would have the same destination location and by proxy the same child_internal_location_ids Speed up: 1000 stock move lines: Before: 2 mins After: 1 mins --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233467 Forward-Port-Of: odoo/odoo#210142
This update makes the quote builder test suite more resilient when a third-party module changes the names of sales order statuses. It helps keep automated checks reliable without affecting normal business users directly.
Original PR description
### Description of the issue/feature this PR addresses: This ensures that `sale_pdf_quote_builder` tests pass even if a third party module that renames `sale.order` `state` selections has been installed. ### Current behavior before PR: Tests fail. ### Desired behavior after PR is merged: Tests pass. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232760
The system now explains more clearly when a file is rejected because it belongs to an uninstalled module or add-on. This should make troubleshooting faster by helping users and support teams understand the cause without digging into the code.
Original PR description
While working on a support ticket, I was faced with this exception handling: https://github.com/odoo/odoo/blob/49061347c181b1a451435bc363bb9508db8b6fab/odoo/addons/base/models/ir_asset.py#L344-L346 It might be nitpicky, but given the if condition, the exception error text could be more explicit about the fact that it's raised because the files in question being from an uninstalled addon/module. This might fast track troubleshooting without having to dive into the source code to understand why the error is being raised. There is always the possibility that I might be missing some context or other scenarios where this error could be raised. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179889
Resolved issues and error corrections
The Time Off dashboard now correctly shows an employee’s Extra Hours allocation when attendance generates overtime. This fixes a visibility issue so managers and employees can see the full balance they are entitled to.
Original PR description
### Steps to reproduce: - Install Attendance and Time off apps - Create some attendance with extra hours for the employee - Go to the employee's time off dashboard - Notice Extra Hours allocation is not shown ### Cause: When we are getting the allocation data we check for the leave types that require allocation https://github.com/odoo/odoo/blob/5f6d2afa8c09fe72c01d056ebef01214567a4a99/addons/hr_holidays/models/hr_leave_type.py#L473 And then when checking the types that doesn't require allocation we are looping on the res that we got from the super which already excluded those types https://github.com/odoo/odoo/blob/5f6d2afa8c09fe72c01d056ebef01214567a4a99/addons/hr_holidays_attendance/models/hr_leave_type.py#L41-L43 ### Fix: We loop over the self leave types to make sure we are getting all of the employee's leave data whether the type requires allocation or not. opw-5042325 Forward-Port-Of: odoo/odoo#234426 Forward-Port-Of: odoo/odoo#225015
When a chat window is opened, the chat hub now resets to a safe position and cannot be dragged while chat windows are open. This prevents the hub from being covered up and makes it consistently accessible to users.
Original PR description
Prior to this commit, moving the chat hub could cause newly opened chat windows to appear on top of it, rendering the hub invisible and unusable. This commit fixes the issue by resetting the chat hub's position whenever a chat window opens and disabling its drag functionality while any chat window remains open. task-5227499 Forward-Port-Of: odoo/odoo#234367
This change avoids doing extra internal cache refreshes when product variant data hasn’t actually changed. It helps keep product operations more efficient without changing the end result for users.
Original PR description
Description of the issue/feature this PR addresses: Method `product.template._create_variant_ids()` triggers a `write()` on `product.product.product_template_attribute_value_ids` which will, in turn, invalidate the cache. This cache invalidation is unnecessary if the new value is the same as the old value. 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#233677
This fix ensures customers receive the expected email when an order status update comes back from Gelato. It prevents missed notifications so order communication stays consistent and customers are kept informed.
Original PR description
Fix not sending the email to customer, when order status update was received from Gelato. opw-4962878 Forward-Port-Of: odoo/odoo#234017 Forward-Port-Of: odoo/odoo#233587
This update prevents a crash when tracking changes on linked records that do not have a display name. Instead of failing, the system now falls back to a safe default, matching the behavior already used in similar situations.
Original PR description
Description of the issue/feature this PR addresses: Addresses: https://github.com/odoo/odoo/issues/178883 Same issue is also in 18.0. Is there a separate PR necessary or will this be ported forward? Current behavior before PR: An error is displayed when tracking is activated on one2many and many2many with records without display_name. Desired behavior after PR is merged: Should not crash and use fallback like in other cases. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214121
The live chat dashboard now excludes unrated sessions when calculating the rating percentage. This makes the displayed score match the reporting view more closely and gives managers a more reliable view of customer satisfaction.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ Before this change, the live chat rating percentage in the dashboard included sessions that were not rated, which made the overall rating misleading. While the sessions reporting view allowed filtering on "rating is set", the dashboard did not provide this option. **Current behavior before PR:** --------------------------------- - Unrated sessions are included in the dashboard rating percentage - The percentage is misleading compared to the sessions reporting view **Desired behavior after PR is merged:** ----------------------------------------- - The dashboard rating percentage only considers sessions with a rating - Unrated sessions are excluded, resulting in a more accurate rating display **Task:** 5048700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227474
This update fixes an error that could happen when opening very large Excel files and converting them into Odoo spreadsheets. It helps users work with big documents more reliably, avoiding unexpected crashes during import.
Original PR description
Steps to reproduce: - upload a large xlsx file (e.g. with >1000 sheets) - open it and convert it to o-spreadsheet => traceback Task: 5222481 Forward-Port-Of: odoo/enterprise#98482 Forward-Port-Of: odoo/enterprise#98443
This change resolves an error that could block confirming or adjusting a manufacturing order created from the Bill of Materials overview when the product has a two-level BoM. Users can now proceed normally with the manufacturing order, without being interrupted by this issue.
Original PR description
This PR fixes the error that occurs when confirming an MO from the BoM overview for a product with a 2 level BoM.
Bug Reproduction:
1- Create BoM for a Main Product.
2- Create a child BoM for any component in the main Product's BoM and make that component have an MTO route.
3- Navigate to the BoM Overview of the Main Product.
4- Click "Manufacture" to create an MO for the Main Product.
5- Click the save icon in the MO.
6- There are two scenarios to reproduce the error now:
a- Confirm the MO form.
b- Or update the quantity to produce in the MO.
= The confirmation or update of the MO is blocked, it should be allowed.
The Issue:
A dirty context is being passed from the BoM overview. it sets the `default_product_qty` to be set in the MO. However, when creating the moves necessary for the MO, this makes an issue as `product_qty` should never be set in stock moves, we set `product_uom_qty` instead.
Task-4795105
Forward-Port-Of: odoo/odoo#214305This change prevents repeated IoT event requests from staying open when users switch in and out of a device view. It helps avoid browser connection limits being reached, so the IoT screen remains reliable during normal use.
Original PR description
Steps to reproduce: 1. Pair an IoT box 2. In the IoT form view, click on any device, then click back to return to the IoT form view. 3. Repeat this step multiple times. If you have devtools open, you can see a `/event` fetch request every time you open the device form. Expected behaviour: - When a new request is made, the previous request is cancelled. Actual behaviour: - The previous requests remain active, and eventually no further requests are possible due to browser limits. This behaviour was broken when the longpolling was changed to use the `fetch` method instead of Odoo's `rpc` method. This commit restores the behaviour by using an `AbortController` instance which is aborted when `stopPolling` is called. Manual Forward Port of Enterprise PR: https://github.com/odoo/enterprise/pull/98985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234872
This update makes VAT return checks faster by removing a slow validation and replacing it with a clearer warning when negative amounts are present. It also fixes access issues for companies with branches, so users can refresh and submit returns only when they have the right company access, and the report now uses the correct company currency.
Original PR description
The "No negative amount in VAT report" return check was too slow, we removed it and clean the database. On the other hand, refreshing checks had issues with the access rights when there was company branches. task-id: 5145537 Forward-Port-Of: odoo/enterprise#97125
When a contact has more than one email address, the chatter now correctly matches the existing contact instead of treating the extra address as a new person. This prevents duplicate contact creation when users send a message from the Contacts app.
Original PR description
**Steps to reproduce:** - Go to the `Contacts` app - Create a new contact - Add multiple emails in the email field (e.g. `"test1@example.com,test2@example.com"`) - Click on `Send Message` button in…
**Steps to reproduce:** - Go to the `Contacts` app - Create a new contact - Add multiple emails in the email field (e.g. `"test1@example.com,test2@example.com"`) - Click on `Send Message` button in the chatter - Default recipients are computed for each email - One of them match the contact, the other doesn't but still pass to the badges list - When sending a message, the second mail is considered as a new contact to create **Issue:** Emails coming from an email field with multiple emails are considered separately when added in the chatter recipients. The partner only match the first one which means that the second one creates a duplicate. This seems to be the default behavior when receiving an email from the additional email address of a partner (`If an email is not unique (e.g. multi-email input), only the first found valid email in input is considered.`), but automatically filling the recipients badges in this way seemed unintended. **Fix:** Properly parsed the email field of recipients to match the partner and avoid creating a duplicate when sending a message on a contact page. opw-4929564 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220593
Miscellaneous changes
task-5184489 Related: https://github.com/odoo/enterprise/pull/98193 Forward-Port-Of: odoo/odoo#234625 Forward-Port-Of: odoo/odoo#233275
Original PR description
task-5184489 Related: https://github.com/odoo/enterprise/pull/98193 Forward-Port-Of: odoo/odoo#234625 Forward-Port-Of: odoo/odoo#233275
task-5184489 Related: https://github.com/odoo/odoo/pull/233275 Forward-Port-Of: odoo/enterprise#98949 Forward-Port-Of: odoo/enterprise#98193
Original PR description
task-5184489 Related: https://github.com/odoo/odoo/pull/233275 Forward-Port-Of: odoo/enterprise#98949 Forward-Port-Of: odoo/enterprise#98193
1 change
Resolved issues and error corrections
This change resolves an error that could block confirming or updating a manufacturing order when it is created from the Bill of Materials overview, especially for products with multi-level BoMs. As a result, users can complete manufacturing actions normally instead of being interrupted by a technical error.
Original PR description
This PR fixes the error that occurs when confirming an MO from the BoM overview for a product with a 2 level BoM.
Bug Reproduction:
1- Create BoM for a Main Product.
2- Create a child BoM for any component in the main Product's BoM and make that component have an MTO route.
3- Navigate to the BoM Overview of the Main Product.
4- Click "Manufacture" to create an MO for the Main Product.
5- Click the save icon in the MO.
6- There are two scenarios to reproduce the error now:
a- Confirm the MO form.
b- Or update the quantity to produce in the MO.
= The confirmation or update of the MO is blocked, it should be allowed.
The Issue:
A dirty context is being passed from the BoM overview. it sets the `default_product_qty` to be set in the MO. However, when creating the moves necessary for the MO, this makes an issue as `product_qty` should never be set in stock moves, we set `product_uom_qty` instead.
Task-4795105
Forward-Port-Of: odoo/odoo#2143051 change
Resolved issues and error corrections
This change prevents an access error when a shared analytic account is used across multiple companies in budget-related purchase orders. It ensures users only see budget information they are allowed to access, avoiding failures when creating or reviewing orders.
Original PR description
Steps to reproduce: - Create an analytic account [ACCOUNT] not restricted to any company - Create an analytical distribution model applying [ACCOUNT] to [PRODUCT] not restricted to any company - Create a budget in company [COMP A] using analytic account [ACCOUNT] - Create a budget in company [COMP B] using analytic account [ACCOUNT] - In company [COMP B], create a purchase order, add [PRODUCT] to a line Issue: Access Error is raised Analysis: Because we search with sudo company rules are bypassed and the system assign both budget lines to the order line (budget_line_ids). When we access the field, the system try to access the budget line of the other company, causing the error. As solution we revert https://github.com/odoo-dev/enterprise/commit/4941c1928c9a2bcb38af3cadf023f904c9fd9be0 removing the `sudo` on the search and we explicitly check if the user has read access on the budget analytic model opw-5056712