Daily updates from Odoo
Monday, January 19, 2026
55 changes · master
Resolved issues and error corrections
This update optimizes the SQL query used to generate budget reports, resulting in significantly faster processing times, especially with large datasets. The change refactors the query to use a more efficient join strategy, avoiding a slow, default approach. This improves the overall responsiveness of the budget reporting feature.
Original PR description
Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`.…
Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`. Because this condition lacks a strict equality constraint, the planner cannot build a hash table for the join. Consequently, it is forced to fallback to a Nested Loop Join strategy, evaluating the condition as a filter for every row pair. This results in significant performance degradation on large datasets. This commit optimizes the query by splitting the logic into two separate `SELECT` statements combined with a `UNION ALL`: 1. Matches where `company_id` is explicitly equal. 2. Matches where `company_id` is NULL. By separating these conditions, the planner can now prioritize a Hash Join for the equality check and handle the NULL join separately, significantly reducing execution time. References: - Original PR introducing the logic: https://github.com/odoo/enterprise/pull/82955 - Plan Before (Join Filter): https://explain.dalibo.com/plan/a55476hgb73ea7g6#plan - Plan After (Hash Cond): https://explain.dalibo.com/plan/3b9g484569a86efb#plan opw-5460862 Forward-Port-Of: odoo/enterprise#104663 Forward-Port-Of: odoo/enterprise#104299
This update resolves an issue where the HTML editor was incorrectly adding tabs to various content blocks, causing unexpected indentation when users selected mixed content. The fix now ensures tabs are only applied to contenteditable paragraph blocks, improving editor usability and preventing formatting errors.
Original PR description
#### Description of the issue this PR addresses: - Tab indentation was applied to non-paragraph and non-contenteditable blocks, leading to incorrect indentation behavior when a selection contained mixed block types. #### Desired behavior after PR is merged: - Filter selected blocks to indent only contenteditable paragraph-related elements (h1–h6, p, pre, blockquote, and div.o-paragraph), while excluding blocks marked as contenteditable="false". #### Steps to Reproduce: - Open a new to-do record. - Insert: Table, Table of Content, Banners, attachment, (18.2 - Toggle List) - Select all editor content using Ctrl + A. - Press the Tab key multiple times. => Multiple editor tab characters are inserted at unintended positions. task-5452410 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243635 Forward-Port-Of: odoo/odoo#241806
This update resolves an issue where editing event organizers (like 'My Company') in the website editor caused errors due to an incorrectly formatted domain. The fix prevents the website editor from passing invalid domain strings, ensuring smooth operation when creating and managing event organizers.
Original PR description
Currently, editing the address or organizer on an event page in website editor triggers an error due to an invalid, unevaluated domain being passed. **Steps to reproduce:** 1. Install `website_event`…
Currently, editing the address or organizer on an event page in website editor triggers an error due to an invalid, unevaluated domain being passed.
**Steps to reproduce:**
1. Install `website_event` module with demo data.
2. Open any event page and activate the website editor.
3. Click on My Company under **Organizers** (also works with **Location**).
4. On the right sidebar click on "**Contact**" drop-down.
**Error:**
`ValueError: Domain() invalid item in domain: ')'`
**Cause:**
The fields `event.event.address_id` and `event.event.organizer_id` have `check_company=True`, which generates in a domain expression like this at [1]:
```
(company_id and ['|', ('company_id', '=', False), ('company_id', 'parent_of', [company_id])] or ['|',
('company_id', '=', False), ('company_id', 'parent_of', '')]) + []
```
This domain is not evaluated on the back-end; instead serialized as JSON string. When the website editor opens the many2one dropdown, the JS code (ref 2) incorrectly splits this string into a list of individual characters, for example:
```
['(', 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', ' ', 'a', 'n', 'd', ' ', '[', "'", '|', "'", ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd',
"'", ',', ' ', "'", '=', "'", ',', ' ', 'F', 'a', 'l', 's', 'e', ')', ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', "'", ',', ' ', "'", 'p', 'a', 'r',
'e', 'n', 't', '_', 'o', 'f', "'", ',', ' ', '[', 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', ']', ')', ']', ' ', 'o', 'r', ' ', '[', "'", '|', "'", ',', ' ', '(', "'",
'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', "'", ',', ' ', "'", '=', "'", ',', ' ', 'F', 'a', 'l', 's', 'e', ')', ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n',
'y', '_', 'i', 'd', "'", ',', ' ', "'", 'p', 'a', 'r', 'e', 'n', 't', '_', 'o', 'f', "'", ',', ' ', "'", "'", ')', ']', ')', ' ', '+', ' ', '(', '[', ']', ')', ['id', 'not in', [1]]]
```
Such a malformed domain passed directly to `name_search()` method, where **Domain()** fails to validate it, raising the error.
**Fix:**
This commit checks for unevaluated domains (returned as strings) and ignores them when rendering many2one fields in the website editor.
[1] - https://github.com/odoo/odoo/blob/9bf7a6511711cbd4866bec03dce5cd08d7580065/addons/html_editor/models/ir_qweb_fields.py#L255
[2] - https://github.com/odoo/odoo/blob/9bf7a6511711cbd4866bec03dce5cd08d7580065/addons/html_builder/static/src/core/building_blocks/select_many2x.js#L102-L109
sentry-6916986959
Forward-Port-Of: odoo/odoo#238825This update removes an unnecessary restriction that prevented users from inserting records into lists grouped by many2many fields. The change clarifies the process for inserting records from these lists, improving usability and functionality. This resolves a previous limitation that was not providing a clear benefit.
Original PR description
When we introduced the record-specific insertion from a list, we added a limitation on lists grouped by many2many fields but this limitation makes no sense, it only blocks the users without any clear reason. Task: 5267035 Forward-Port-Of: odoo/enterprise#103869 Forward-Port-Of: odoo/enterprise#103161
This update fixes an issue where the Builder List component was forcing developers to include default values for props, even when those values weren't needed. Now, the system only validates default props if actual props are provided, streamlining the development process and reducing unnecessary configurations. This ensures a more efficient and flexible Builder List experience.
Original PR description
Previously we validating the `default` props with the defaultPropsValue If someone didn't passed the props. which force to pass the default value even it isn't needed. 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
This update fixes an issue where receiving products with negative quantities resulted in incorrect average cost calculations, leading to negative inventory values. The change ensures that when inventory levels are negative, the standard cost is updated to the last received cost, preventing inaccurate financial reporting.
Original PR description
## Issue When doing a receipt with a different Unit Cost than the current one in negative quantity, the average cost would become aberrant. ## Steps to Reproduce - Create product P, Average Costing method, cost at 0 - Create & Validate a delivery for 10 unit of P - Create & Confirm a Purchase Order for 5 Units of 0 at *10 / Unit - Receive the 5 Units ==>> The product standard cost becomes $-10 ! This is because the system sees -5 Units on hand for a total of $50, and do the average. In Odoo 18, the Delivery would have been reevaluated to the receipt value, so the total value after the receipt would have been $0 for -5 Units. ## Solution When the product quantity is negative, we use the cost from the last receipt as the new average cost. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243813
This update clarifies how preset selections work within the Point of Sale (POS) system. Specifically, it now visually indicates when preset options are presented as pop-ups, aligning with a recent change in how two-preset selections are handled. This ensures a smoother and more intuitive user experience for POS operations.
Original PR description
In this commit: =============== Update POS tours to explicitly indicate popup usage when selecting presets, to support the new auto-toggle behavior introduced when only two presets are configured. Task-5491093 Related Comm. PR: https://github.com/odoo/odoo/pull/244455
This update resolves an issue where the 'Other Input' section of the Payroll app incorrectly displayed trailing zeros for negative salary attachment counts. The fix adjusts a widget to properly handle negative values, ensuring accurate reporting of negative amounts. This improves the clarity and reliability of payroll data.
Original PR description
Steps to Reproduce: - install Payroll app - create an employee and create a salary attachment. - check the negative value for salary attachment - generate a payslip Issue: - In "Other Input" section, salary attachment count displays value with trailing decimal zeros for negative amounts. Reason: - The field is using the widget float_without_trailing_zeros which should remove the extra decimal zeros but it doesn't work when the value is negative. Solution: - Fix the regular expression in the float_without_trailing_zeros widget to handle negative values and properly remove trailing decimal zeros. task-5477466 Forward-Port-Of: odoo/odoo#243074
This update resolves a technical error within the WPS report testing process. Previously, a test was incorrectly creating bank records, which has now been corrected by ensuring the correct company ID is used. This ensures accurate report generation and data integrity.
Original PR description
The test was creating a res.partner.bank with the id of company passed as partner_id. This commit fixes this issue by passing the partner_id of the company instead. build_error-237562
This update corrects a problem where product images weren't consistently being removed from the website, particularly for products with variations. The fix ensures the image is fully loaded into the webpage before the removal button is clicked, preventing errors and improving the user experience. This ensures accurate product displays on the website.
Original PR description
With this commit, we fix tours: - website_sale.remove_main_product_image_with_variant - website_sale.add_and_remove_main_product_image_no_variant where we want to remove the product image. This fix add a step to ensure the image is in DOM before clicking on the remove button. error-runbot-id~237766 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
This update simplifies the handling of recoverable amounts in return payments. Instead of automatic propagation, users can now manually deduct these amounts within the payment wizard, triggering a reconciliation move. This provides greater control and accuracy when processing returns.
Original PR description
Now we removed the automatic propagation of the recoverable amount from closing to closing. Instead the balance under the return amount shows the amount that is left to pay. And if we want, in the pay wizard, we can deduct the recoverable amount from the amount to pay for the period. When doing this, a reconciliation move is automatically made. task-5172274
This update resolves a technical issue that prevented demo data from installing correctly. The problem stemmed from a missing timezone setting for employees, introduced during a recent update to the working schedule. This fix ensures demo data installs without errors.
Original PR description
This PR fixes a bug in a test when demo data is installed. A timezone setting was missing on the employee. The refatoring PR of the working schedule (https://github.com/odoo/enterprise/pull/96139) introduced the issue. Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/238014 task-5704131
This update resolves a problem where scanning barcodes on picking orders with kit product variants would cause an error. The fix ensures that packaging information is correctly captured during barcode scans, allowing for accurate tracking of kit components.
Original PR description
In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback. ### Steps to reproduce: 1. Enable packagings on inventory configuration.…
In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback. ### Steps to reproduce: 1. Enable packagings on inventory configuration. 2. Create a product, that as a least 2 variants. 3. Add a packaging to one of the variants. 4. Create a BoM for created product (kit type). 5. Create a picking order for the variant with packaging. 6. Print the picking operation to scan the code through barcode. 7. Go to barcode and try to scan it, this will trigger the traceback. ### Cause of the issue: Scaning a barcode will call get_barcode_data during this call it will retrieve the information about the picking order and call _get_stock_barcode_data: https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode/controllers/stock_barcode.py#L91 _get_stock_barcode_data will obtain the packaging methode for the products. https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode_mrp/models/stock_picking.py#L13-L16 since in our use case the product has variant the packaging information is not inside product_tmpl_id.packaging_ids and thereof it will not retrieve the packaging information. ### Fix: We don't need to use product_tmpl_id.packaging_ids because of its compute and set methods (and the fact that the product_variant_ids field is required), the product_tmpl_id.packaging_ids will always be included in the product_tmpl_id.product_variant_ids.packaging_ids: https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/product/models/product_template.py#L430-L441 our fix will allow for packaging in the variant to be considered when there is more than only one variant. opw-4852875 Forward-Port-Of: odoo/enterprise#103860 Forward-Port-Of: odoo/enterprise#87867
This update clarifies the 'Do Not Disturb' (DND) icon in the softphone interface. Previously, the DND icon was visually similar to other status indicators, leading to potential user confusion. This change ensures a clearer visual distinction for the DND status, improving usability.
Original PR description
This commit updates the DND icons in the softphone to avoid confusion with other status icons represented by a colored dot. task-5479064 Requires: - https://github.com/odoo/odoo/pull/244291 | Before | After | |--------|--------| | <img width="168" height="91" alt="Capture d’écran 2026-01-16 à 16 15 32" src="https://github.com/user-attachments/assets/ad7447d2-8d8d-4963-abf8-6b4ac27270c0" /> | <img width="155" height="86" alt="Capture d’écran 2026-01-16 à 16 16 17" src="https://github.com/user-attachments/assets/485ec299-1f39-4bc4-84c8-199c0bbdf6cc" /> | | <img width="399" height="159" alt="Capture d’écran 2026-01-16 à 16 16 58" src="https://github.com/user-attachments/assets/c590e7bf-c3ee-45c7-a6bf-69080c2a158c" /> | <img width="397" height="156" alt="Capture d’écran 2026-01-16 à 16 17 32" src="https://github.com/user-attachments/assets/32b3ec65-4ca4-492a-a9c4-642b16be5340" /> |
This update enhances the message list by displaying specific error details when loading messages fails. Previously, users only saw a generic 'An error occurred' message. Now, users receive a more informative error message, providing a clue about the cause of the failure and reducing frustration.
Original PR description
Before this commit, when message list failed to load, it just displays a "Ann error occurred" generic message with a retry button. This assumes that error happens rarely and when so this is temporarily. However some errors are persistent and it's frustrating to have no clue on why there's error or what may have caused it. This commit shows the `Error.toString()` from fetch message RPC failure on UI, so that there's a clue on the reason the fetch of messages failed. Before / After <img width="322" height="78" alt="Screenshot 2026-01-15 at 18 18 31" src="https://github.com/user-attachments/assets/81873d16-c489-4be8-b2de-64f7dec2215e" /> <img width="347" height="91" alt="Screenshot 2026-01-15 at 18 17 44" src="https://github.com/user-attachments/assets/90bc09e6-99a8-4722-92d0-f972aee20b36" />
This update ensures that optional field toggles within the Odoo list view are always visible above column resize handles. Previously, these toggles could be obscured, making it harder for users to quickly select or deselect optional fields. This change improves the user experience and clarity of the list view.
Original PR description
This commit increases the z-index of the toggle of the optional field dropdown s.t. it is always above the column resize handle. Task~5504022 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
This update resolves an issue preventing the bank reconciliation view from functioning correctly offline. The change disables caching for this specific view, ensuring it can access data even without an internet connection. This improves the reliability of this key financial reporting tool.
This update fixes a bug in the chatbot where invalid phone numbers were accepted, leading to inaccurate data. Now, the chatbot validates phone input, displaying an error message and preventing users from proceeding until a valid number is entered, ensuring reliable contact information.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ Before this change, the chatbot phone step allowed any input, including invalid characters, leading to incorrect phone numbers and inconsistent data. **Current behavior before PR:** --------------------------------- - Phone step accepts any input - Users can proceed with invalid numbers **Desired behavior after PR is merged:** ----------------------------------------- - Phone input is validated in the chatbot - Invalid numbers show an error message: `'xxx' does not look like a valid phone number. Can you please try again?'` - Users cannot proceed until a valid number is entered **Task:** 4949441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where excessive logging was appearing in Odoo's unit tests. By hiding these logs, the tests now run more efficiently and reliably. This improves the overall stability and performance of the Odoo platform.
Original PR description
This commit hides unwanted logs in unit tests check_undeterminisms 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
This update corrects an issue where valid Mexican account numbers (CLABE) were incorrectly formatted with spaces. This change ensures that payroll reports generated for Mexico comply with EDI standards, preventing errors in reporting and financial processing. The fix utilizes a sanitized account number to guarantee accurate data transmission.
Original PR description
Before this commit, an account number that is a valid CLABE would be formatted with spaces. Reporting this account number then in the mexican EDI would be wrong because it's expected to have no spaces. This commit solves this issue by reporting the sanitized_account_number instead. task-5727295
This update enhances how users manage their consent for online account synchronization. The change allows for a more flexible approach to handling consent requests, addressing a previous technical issue. This improves the user experience and ensures compliance with data privacy regulations.
Original PR description
In this commit:https://github.com/odoo/enterprise/commit/bf5b7d03fe8e138ee8bc0246d3d148638db5d620 we introduce a message on the account_online_link to be able to manage the consent. But since manage_consent is not a field of account.online.linki would traceback, we changed the position of the code by popping the value. Also changed the url to use the provider_type to be able to use the route with any provider if needed task-5187621 Forward-Port-Of: odoo/enterprise#104519 Forward-Port-Of: odoo/enterprise#102428
This update addresses several small issues within the l10n_hr_edi module, primarily focused on improving error handling and the user interface. Specifically, it enhances the process of fiscal document status checks, supports multi-company operations, and streamlines bill approval workflows. These changes ensure greater stability and usability for users.
Original PR description
- Adjusting error handling for receiving an empty response from MER for a document fiscalization status. - Adding additional checks for running multi-company-wide MER API methods. - Adjusting how approval API call is handled when confirming a bill. - Adding a tooltip about Company BU in MER settings and missing "company dependent" indicators for the credentials. Continuation of task-4925745 Related to opw-5477846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244357 Forward-Port-Of: odoo/odoo#244023
This update corrects a data issue within the Odoo Enterprise system related to Chilean SII (Service de Impuestos Internos) reporting. Specifically, the information for the 'Alto Hospicio' Regional Office and its associated Comuna (Alto Hospicio) within the Taracapá region has been added, ensuring accurate tax reporting compliance.
Original PR description
Oficina Regional Alto Hospicio Comuna Alto Hospicio Región Taracapá Forward-Port-Of: odoo/enterprise#102712
This update enhances the customer display popup in Point of Sale, making it easier to access customer information across devices. Now, both desktop and mobile users will see a QR code to scan, and desktop users will also have a button to open the customer display directly on their device. This streamlines the process of viewing customer details during transactions.
Original PR description
Changed to open the QR code popup on the desktop as well. Before it was opening directly in a new window and it was hard to open it on a separate device. The QR popup will: - on desktop: will show a button to open the customer display on the same device, or to scan the qr - on mobile: will show only the qr code to scan task-5129241 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243618 Forward-Port-Of: odoo/odoo#229478
This update removes a feature that allowed users to directly open folders from the sync configuration list. This change simplifies the process of selecting and editing configuration rows, leading to a more user-friendly experience. The removal addresses a usability issue that was causing confusion.
Original PR description
Previously, clicking a folder in the sync configuration list redirected the user to the folder view, which made it difficult to select or edit the configuration row. To improve usability, the ability to open folders directly from `documents_account.documents_folder_setting_view_list` has been removed. task-5212503 Forward-Port-Of: odoo/enterprise#103218
This update fixes an issue where numbers extracted from OCR boxes were incorrectly parsed due to language-specific decimal separator settings. The change simplifies the parsing process by consistently using a standard JavaScript `Number` parser, ensuring accurate numerical data entry within the system. This improves data integrity and reliability.
Original PR description
When using a language that doesn't use a dot as decimal separator, the number parsed from the box content was incorrect. For example, if the content of the box was "1234.56", the parsed value would have been "123456". This happened because the float parser available through the registry takes into account the language of the user and its configured thousands/decimal separators. Since the content of the boxes are always formatted as "1234.56", without thousands separator and with a dot as decimal separator, the regular `Number` parser of Javascript can be used to get consistent results. opw-[5427979](https://www.odoo.com/odoo/49/tasks/5427979) Forward-Port-Of: odoo/enterprise#104467
This update fixes an issue where cash order creation in Point of Sale was missing essential information like company and user details. Previously, orders weren't properly linked, leading to potential data discrepancies. This change ensures cash orders are created with accurate context, improving order tracking and reporting.
Original PR description
Before this commit, the order for cash moves was created without setting the session_id, company_id, and user_id fields. opw-5500966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244287
This update fixes an issue where order processing within batch picking was inconsistent. The change ensures that order lines are correctly associated with picking IDs by using the ID field instead of the field itself, resolving a technical problem related to how Odoo compares related data. This improves the reliability of batch picking operations.
Original PR description
Ordering recordset based on relationnal field should always take the relational field's `.id` instead of the field itself. This is due to the BaseModel `__gt__` override comparing if a set is included into another and not if the `id` is bigger that the other `id`. runbot : 237512 Forward-Port-Of: odoo/enterprise#104561
This update fixes a problem with the Point of Sale testing process. Previously, the tour wouldn't always complete successfully. By adding a final check to ensure at least one paid order exists, the tour now reliably finishes, guaranteeing consistent and accurate test results. This improves the quality of our Point of Sale testing.
Original PR description
By adding a last step ( that check that there is at least one paid order), we ensure that the RPC is done before closing the tour. error-runbot-id~233511 error-runbot-id~232677 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#243815
This update resolves an issue where group channels (DMs with fewer than 3 members) were causing confusing display behaviors like incorrect status indicators and missing author names. By removing a specific calculation, the system now accurately reflects the nature of group channels, providing a more reliable user experience.
Original PR description
Before this commit, the "correspondent" property of Thread would be computed for channels of type group (group DMs) having less than 3 members. This would lead to various confusing behaviours, including: 1. The "back on" banner being shown. 2. The chat bubble showing an IM status. 3. The notification item not showing the message author's name. This commit fixes the issues by not computing `correspondent` for channels of type group. task-5462395 Forward-Port-Of: odoo/odoo#243874 Forward-Port-Of: odoo/odoo#242058
This update fixes a technical issue that caused tracebacks when a member was typing in group chats with multiple users. The fix ensures that the 'ImStatus' component isn't incorrectly displayed in group chats, preventing errors and improving stability. This resolves a potential disruption for users engaging in group conversations.
Original PR description
Before this commit, when another member of a group chat with more than 2 members was typing it would result in a traceback. Steps to reproduce: 1. Have `hr_homeworking` and/or `hr_holidays` installed 2. Create group chat with 2 other users 3. Open said group chat 4. Have another member start typing -> traceback This happens because since [1] the condition to show the `ImStatus` component became `showImStatus`, which is true in group chats when another member is typing. However since group chats with more than 2 members have no correspondent, this leads to the `ImStatus` component having no `persona` attribute, which in turn causes a crashes in templates without a guard on `persona` access. This commit fixes the issue by making `showImStatus` only true in DMs, since it's not expected for group chats to have a correspondent and hence an IM status should not be shown. [1]: https://github.com/odoo/odoo/pull/234715 Forward-Port-Of: odoo/odoo#243798
This update adjusts the size of the 'looking for help' timers in live chat conversations on the discuss sidebar. The change makes the overall text content of these conversations more visually balanced, improving readability and the user experience. This is a minor cosmetic fix.
Original PR description
Timers on "looking for help" live chat conversations on discuss sidebar were slightly too big. This commit reduces the size to make the overal text content of a discuss item more balanced. Before / After <img width="296" height="100" alt="Screenshot 2026-01-16 at 16 58 50" src="https://github.com/user-attachments/assets/32d8e304-c00f-4d2f-bcb9-3b58be7f01c4" /> <img width="298" height="99" alt="Screenshot 2026-01-16 at 16 58 57" src="https://github.com/user-attachments/assets/2cc6fff7-8613-4b56-b44c-22ad72738286" /> Forward-Port-Of: odoo/odoo#244306
This update ensures that newly created General(MISC) entries in Odoo automatically have 'no follow-up' enabled. This simplifies reporting and prevents unnecessary notifications for these common transaction types, streamlining our accounting processes. It’s a small change that improves efficiency and reduces potential noise in our reporting.
Original PR description
General(MISC) entries should be no_followup by default. task-5489772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244309
This fix addresses an issue where a project was automatically created when ordering 0 units of a prepaid service product within a quotation. The change ensures that projects are only created when a valid quantity of the service is ordered, streamlining the quoting process and preventing unnecessary project creation. This resolves a potential confusion and improves data accuracy.
Original PR description
--- ## Short functional explanation of the error Let's say we have a prepaid service as a product, generating a project upon order. When we order 0 units of this product as an optional product, a project is still created. ## Reproduction Steps 1. Create a product of type Service. Set Project in the field Create On Order. Set the Invoicing Policy at Prepaid. 2. Create a quotation containing an optional product with 0 units of this service and click on confirm. ### Expected behavior The quotation is confirmed, but no project is created. ### Unexpected behavior A project linked to the product and the quotation is created. ## Origin of the issue When creating projects linked to order lines, we don't check if such projects are linked to optional products. opw-5406118 Forward-Port-Of: odoo/odoo#240608
This update corrects a bug where invoices could be incorrectly linked to DIAN documents after a rejection. When a DIAN error occurs, the system now verifies key details (customer, date, time) between Odoo and the DIAN XML to ensure accurate linking, preventing data mismatches.
Original PR description
**Steps to reproduce:** (only reproducible in production) - Install accountant and l10n_co_dian - Switch to a Colombian company (e.g. CO Company) - In Accounting settings, configure the Colombian…
**Steps to reproduce:** (only reproducible in production) - Install accountant and l10n_co_dian - Switch to a Colombian company (e.g. CO Company) - In Accounting settings, configure the Colombian localization with valid DIAN credentials - Create an invoice for a Colombian customer - Confirm the invoice - Send the invoice to DIAN - Cancel and delete the invoice - Create another invoice for another Colombian customer with the same name (sequence) than the previously deleted invoice - Confirm the invoice - Send the invoice to DIAN **Issue:** A previous fix (https://github.com/odoo/enterprise/commit/4d782030631350cfaa8f2993e68f33c9f66929e4) had been made to sync together a DIAN document from Odoo and DIAN when the following error was returned by DIAN: "Regla: 90, Rechazo: Documento procesado anteriormente." It can happen when an invoice is sent to DIAN but due to a connection issue, the DIAN response is not received and the invoice is flagged as rejected. In that case, the "Regla: 90" error is returned by DIAN when trying to send the invoice again and the fix is linking the identifier returned by the DIAN error with the invoice to prevent this issue. However, the fix wasn't taking into account the case in which the error returned by DIAN is legit and the identifier is linked to another document. It results of having an invoice that is linked to an incorrect document in DIAN. The customer, date and other info, completely different. **Solution:** When "Regla: 90" error is returned by DIAN, a check is performed to make sure that the customer, the issue date and time on the document in Odoo and on the XML from DIAN are the same before assigning the identifier from DIAN to the document in Odoo. opw-5095212 Forward-Port-Of: odoo/enterprise#99936
This update fixes an issue where tax names and invoice labels were displayed in English for Vietnamese users. By adding Vietnamese translation columns to the tax template CSV, the system now correctly displays tax labels in Vietnamese, improving the user experience for Vietnamese-speaking businesses. This ensures accurate and localized reporting for our Vietnamese clients.
Original PR description
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused…
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused tax names and invoice labels to display in English even when the user's language was set to Vietnamese. By adding the `name@vi_VN` and `invoice_label@vi_VN` columns to the tax template CSV, taxes will now display with proper Vietnamese labels when the chart of accounts is installed for Vietnamese companies, improving the user experience for Vietnamese-speaking users. Technical details: - Added `name@vi_VN` and `invoice_label@vi_VN` columns to the CSV header - Added Vietnamese translations for all tax records in the template - Translations follow Vietnamese tax terminology conventions - The chart template loader automatically processes columns with `@lang` suffix and applies them as translations for translatable fields 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#244151 Forward-Port-Of: odoo/odoo#236502
This update resolves a technical issue causing duplicate entries in the Accounts Coverage Report, specifically when using the Ireland reports. The fix ensures accurate reporting by ignoring identical report lines with the same name and code, preventing misleading results.
Original PR description
Reproduce the bug: -Install Ireland(ie) reports -Enable debug mode -Go to Reporting>Balance Sheet>Accounts Coverage Report -The generated sheet should have false positive duplicates error Fix: Ignore the report lines that has the same name and the same code task: 5373732 Forward-Port-Of: odoo/enterprise#101311
A technical issue prevented the correct installation of the l10n_be_hr_payroll module. This update resolved a conflict related to a field definition, ensuring the module functions properly when installed independently. This change improves the stability and usability of the Belgian payroll functionality.
Original PR description
A traceback about bike_id occurs when only installing l10n_be_hr_payroll. The field bike_id is in the fleet bridge of the belgian payroll. The field is already present in the _get_whitelist_fields_from_template method in that module. Removing the field from the l10n_be_hr_payroll method solves the issue. Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/234856 task-5504273 Forward-Port-Of: odoo/enterprise#104612
A technical issue in the tour test was causing it to incorrectly select contacts. This update resolves the problem by ensuring the tour always uses the correct contact associated with the call being demonstrated, specifically selecting from the Recent tab instead of the Contact tab when demo data is used.
Original PR description
`call_activity_chatter_link` tour fails when test contains demo data. When contains demo data, the test select a wrong contact in Contact tab. In this commit, we change to select the first call in Recent tab to ensure this is the contact of the call we just made. Forward-Port-Of: odoo/enterprise#104687
This update resolves a problem where customers couldn't change product selections within the Point of Sale configurator. The issue stemmed from overly restrictive attribute exclusions, preventing valid combinations. The fix removes the problematic code to allow customers to freely select product options.
Original PR description
Step to reproduce: - Create 2 attributes with 2 values each A1V1 A1V2 and A2V1 A2V2 - Create a product with these attributes and set the attribute exclusion so that only 2 valid combinations are…
Step to reproduce: - Create 2 attributes with 2 values each A1V1 A1V2 and A2V1 A2V2 - Create a product with these attributes and set the attribute exclusion so that only 2 valid combinations are possible. (ex: a1v1 excludes a2v2 and a1v2 excludes a2v1) - Open PoS and try to add the product to the cart. - The configurator popup will appear. Observation: - You will not be able to change the selection because the other combinations are not correct. Cause: - The issue was already fixed [1] but issue was reintroduced in [2] Fix: - Remove the code, which was causing the issue, we shouldn't disable an option and allow customer to change the combiantion [1] https://github.com/odoo/odoo/commit/5864780ed703f61d763e1b49c33da3bbf8ca32f2 [2] https://github.com/odoo/odoo/commit/6e7c663543ba2b219d492795971f42e3e2c1213e opw-5418977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244347 Forward-Port-Of: odoo/odoo#241259
This update resolves a recurring issue where the quotation signing tour occasionally failed to complete correctly. The fix adds a deliberate pause within the tour to ensure all interactions have finished loading, resulting in a more stable and reliable experience for users. This enhances the overall usability of the sale management process.
Original PR description
This commit fixes the flaky quotation signing tour in sale_management by adding an explicit step to wait for interactions to fully load before proceeding with the next steps. runbot error-224021 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242848 Forward-Port-Of: odoo/odoo#242746
This update resolves a technical issue where the HTML editor would crash when attempting to remove formatting from a cell with a lingering color. Now, users can reliably remove colors from empty cells without encountering errors, improving the overall stability and usability of the editor.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a m x n table - Write some text in a cell, apply color on text - Delete text and keep empty colored element - Select cell - Trying to remove format throws infinite loop error in removeAllColor **Desired behavior after PR is merged:** Clicking on remove format button should remove color from empty colored element without causing traceback. task-5454993 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243976 Forward-Port-Of: odoo/odoo#241829
This update fixes an issue where the POS product information popup only showed the first tax applied to a product. Now, the popup correctly displays all tax names, separated by commas, providing customers with accurate tax details. This improves transparency and ensures correct pricing calculations in the Point of Sale system.
Original PR description
Before this commit: --- - The POS product info popup displayed only the first tax from `tax_details`, which meant multiple applied taxes were not visible. - The logic fetched a single tax name instead of all tax applied to the product. After this commit: --- - The POS store sends a full list of tax names instead of a single name. - The popup template displays all tax names, comma-separated. task-5406826 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244284 Forward-Port-Of: odoo/odoo#239813
This update fixes an issue where right-clicking on links within messages was obscured by extra message actions. Now, users will see the standard browser context menu options like 'Open Link' and 'Copy Link' when right-clicking on a message link, improving usability.
Original PR description
Before this commit, when right-clicking on a link in a message body, this was showing the list of message actions in dropdown. This is a problem because right-click on link has features like "Open link" / "Copy link" and so on. They were over-shadowed by the right-click on message for showing of message actions. This commit prevent the showing of message actions in dropdown from right-click in links in message body, so that the browser context menu is open instead in that scenario, showing features like "Open link" and "Copy link". Forward-Port-Of: odoo/odoo#244252
This update resolves a technical error in the Point of Sale system that prevented users from creating order names with custom prefixes. The fix ensures order names, including prefixes, can be generated correctly, preventing tracebacks and ensuring proper order functionality. This improves the reliability of the POS experience.
Original PR description
**Steps to reproduce:** - Go to the sequence interface, and chose the config number 1 for a pos.order - In the prefix field, enter something with characters that are not numbers - Go to a PoS with…
**Steps to reproduce:** - Go to the sequence interface, and chose the config number 1 for a pos.order - In the prefix field, enter something with characters that are not numbers - Go to a PoS with config number 1 active and make a purchase - A traceback appears saying that we can't convert the sequence to an Integer **Why the fix:** Having a custom prefix with letters used to work, but in version 19, we now store the sequence_number with the prefix, which can be composed of characters which can not be stored in an Integer field such as sequence_number. To prevent this error, we remove the prefix and the suffix (which has the same issue) from the sequence_number before storing it. We then add the prefix and the suffix back when computing the order's name, so that it's consistant with the prefix and the suffix the user chose. This is the way the order's name was computed before version 19.0, which saw the prefix and suffix disappear from the order's name. opw-5386575 Forward-Port-Of: odoo/odoo#239515
This update resolves a test failure that occurred when the current date was in 2027. The issue stemmed from a subscription end date set for December 31, 2026, causing a system error when processing invoices in 2027. This ensures the subscription functionality operates correctly across different years.
Original PR description
Before this commit, the test was failing if today date was in 2027. it occured because the end_date of the subscription was on the 31 of December 2026. As a result, when running in 2027, the _create_recurring_invoice method would close the order. runbot-id-237658 Forward-Port-Of: odoo/enterprise#104604
This update enhances the security of our web service connections by allowing us to securely verify server identities using certificate records. Previously, our system struggled with how to properly utilize these certificates, but this change now allows for more robust and secure communication with external services. This improves overall system reliability and security.
Original PR description
Our webservice client (`zeep`) connections lacked a way to use `certificate.certificate` models to verify the connection with server identification. This is rather complicated, since PyOpenSSL only allows filenames with their default methods. We now add the feature to pass these certificate records, load them into memory buffers, and add them to the CA store. IAP PR: odoo/iap-apps#1308 Task [link](https://www.odoo.com/odoo/project.task/5068741) task-5068741 Forward-Port-Of: odoo/odoo#244386 Forward-Port-Of: odoo/odoo#238717
This update fixes an issue where the Netherlands localization incorrectly created duplicate fiscal positions. The change removes the duplicate and properly defines the NL Domestic fiscal position, ensuring accurate VAT handling and compliance with Dutch regulations. This ensures the accounting system functions correctly for Dutch businesses.
Original PR description
Installing the Netherlands localisation creates two Domestic fiscal positions, both incorrectly configured. This commit removes the empty duplicate fiscal position and properly defines the NL Domestic fiscal position by setting the Country Group, leaving Country empty, and disabling VAT requirement. task-5489829 Forward-Port-Of: odoo/odoo#244183
This update fixes an issue where reports were displaying unit prices with incorrect decimal precision. The change removes a technical widget that was overriding the configured Decimal Accuracy settings, ensuring reports now accurately reflect product prices based on the company's currency setup. This improves the accuracy of sales reporting.
Original PR description
Steps to reproduce: 1. Install the Sale app. 2. Enable developer mode and go to Decimal Accuracy. 3. Set the "Product Price" precision to 3 digits. 4. Create a quotation and print the report. Issue:…
Steps to reproduce: 1. Install the Sale app. 2. Enable developer mode and go to Decimal Accuracy. 3. Set the "Product Price" precision to 3 digits. 4. Create a quotation and print the report. Issue: The decimal precision of the unit price is not respected in the report. Cause: The unit price field in the report uses the `monetary` widget, which ignores the Decimal Accuracy configuration and enforces currency precision instead. Solution: Remove the `monetary` widget from the unit price field in the report so that Decimal Accuracy is applied correctly. Before: <img width="570" height="97" alt="image" src="https://github.com/user-attachments/assets/dda22b25-0ade-40ae-b585-c6251ba89c89" /> After : <img width="584" height="87" alt="image" src="https://github.com/user-attachments/assets/b51d3040-e7b5-41d6-bdd9-7ec799b8005d" /> opw-5418665 Revert [PR #224219](https://github.com/odoo/odoo/pull/224219/files#diff-92dda03d204cc6ea8b7aacd0c07939843c83b1841f4a3049903844777d83c07bR201) to the original implementation so that the configured Decimal Accuracy is correctly applied in reports as other apps i.e. Purchase or Account Forward-Port-Of: odoo/odoo#241255
This update resolves a problem where Odoo incorrectly displayed a "Resume" prompt after successfully importing large CSV files in batches. The fix ensures the 'Resume' prompt disappears automatically when the import process is truly complete, improving the user experience. This prevents unnecessary prompts and streamlines the import process.
Original PR description
When importing a large file in multiple batches , Odoo incorrectly displays a "Resume" prompt at the end of the process, even though all records have been successfully imported. Steps to reproduce:…
When importing a large file in multiple batches , Odoo incorrectly displays a "Resume" prompt at the end of the process, even though all records have been successfully imported. Steps to reproduce: 1. Create a CSV file with enough records to trigger at least 2 batches 2. Go to any list view and select "Import records". 3. Upload the file and click "Import". 4. Wait for the import to complete. 5. Observe that despite an "X records successfully imported" notification, a warning "Click 'Resume' to proceed..." appears. The issue occurs because the `importRes.nextrow` state variable is updated during intermediate batches but is not cleared when the final batch completes. * In `_executeImportStep`, if `nextrow` is returned (intermediate batch), `importRes.nextrow` is updated. * If `nextrow` is falsy (final batch), the loop is stopped, but `importRes.nextrow` retains the value from the previous batch. * `executeImport` checks `importRes.nextrow` to decide whether to show the `"Resume"` message, leading to a false positive caused by the stale value. This commit fixes the issue by explicitly setting `importRes.nextrow` to `0` in `_executeImportStep` when the server indicates completion (returns a falsy `nextrow`). opw-5343837 Forward-Port-Of: odoo/odoo#241490
This update corrects inaccuracies in the Spanish balance sheet reports, specifically for Pymes and Completo versions. The fix addresses missing figures and ensures that section totals are correctly calculated, improving the reliability of financial reporting.
Original PR description
Waking up a test that check the balancedness of balance sheet, we check again the Spanish ones: pymes: - subsections were not taken into account into the sum of the section - 296/596 are specific to pymes, but it goes into the overall section - 473 was included. It is not included in documentations because it needs to be emptied at closing, but we want balanced all the time. - 5585 was missing completo: - 200/280/290: research should be expenses at closing, but in the meantime we add it to the other accounts assoc: - 178/189: to deudas a largo plazo can caracteristicas especiales Translation for deudas a largo plazo was changed. Forward-Port-Of: odoo/enterprise#97875
This update resolves an issue where demo data in the stock barcode module incorrectly packed items into existing demo packages instead of new ones. The fix ensures a unique package name is created during demo data installation, preventing this conflict and maintaining accurate inventory tracking.
Original PR description
The test `test_put_in_pack_in_new_created_package` does a simple thing: 1. We scan a product then put it in pack; 2. We scan a second package than scan the package created during previous put in pack. To be sure we scan the package created in 1., we reset the package sequence so we're sure the created package will have 'PACK0000001' as name. The issue is: when demo data are installed, a package with this name is already created, which means when we scan 'PACK0000001' in step 2., instead of packing the second line into the newly created package, we pack it into the demo data package. To avoid that, this commit sets the package's sequence to 42 so we're sure the created package will be named 'PACK0000042'. runbot-build-error: [98126575](https://runbot.odoo.com/odoo/runbot.build.error/237802) Forward-Port-Of: odoo/enterprise#104623
This update corrects a technical issue that was preventing the generation of accurate invoice reports for Mexican EDI (l10n_mx_edi) transactions. The fix prevents an error that occurred when multiple invoices with the same payment method code were processed, ensuring consistent report output.
Original PR description
- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in…
- for more then one records having same code it's raising an singleton error at fetching the name
- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```
- OPW-5450360
Forward-Port-Of: odoo/enterprise#103460A test used to occasionally fail due to a timing issue with notification messages during inventory adjustments. This commit resolves the problem by automatically closing the success notification after the first adjustment, ensuring the subsequent adjustment runs correctly. This improves the reliability of the inventory packaging test.
Original PR description
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The…
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The error message is: `AssertionError: 16.0 != 15.0` In the tour, we do a first inventory adjustment where we set the `proquct1` qty to 16, then we do a second inventory adjustment where we set its qty to 15. Now, the assert sometime fails because in the tour, the last step check the success message is visible: ```javascript trigger: ".o_notification_bar.bg-success", ``` The issue with that is that we already do a first inventory adjstment and its success notification is still visible while processing the second inventory adjustment, creating a race condition. To fix that, we just need to close the first notification message, and to do so, this commit back-ports and uses the step utils' method `checkNotificationMessage` (see [1]) since this method checks a notification message is there and close it. [1]: https://github.com/odoo/enterprise/pull/101495 runbot-build-error: [227692](https://runbot.odoo.com/odoo/runbot.build.error/227692) Forward-Port-Of: odoo/enterprise#104614 Forward-Port-Of: odoo/enterprise#104481
This update resolves an issue where the inventory forecast view incorrectly linked to stock picking records when using manufacturing reservations. The fix ensures the correct manufacturing production record is displayed, preventing duplicate links and inaccurate reporting for products with manufacturing processes.
Original PR description
**Issue:** The forecasted inventory view assumed that line.reservation was always a `stock.picking`. In manufacturing flows, the reservation can be an `mrp.production`, which caused incorrect…
**Issue:** The forecasted inventory view assumed that line.reservation was always a `stock.picking`. In manufacturing flows, the reservation can be an `mrp.production`, which caused incorrect navigation to a `stock.picking` record. Fix this by comparing both model and id when checking if the reservation differs from the outgoing document, and by opening the reservation using its actual model. This ensures the correct document is shown and avoids duplicate or invalid links in the "Used by" column. **Steps to reproduce:** - Create a v19 db with sale,mrp,sale_stock with `--demo-true`. - Go to products -> search for 'FURN_0269' product and open form view. - open forecasted smart button for forecasted reeport. - check the used by column for mrp reservation - i.e,: `WH/MO/00001 - WH/MO/00001` appears twice. - clicking on first, opens correct record of `mrp.production` where the units is reserved. - clicking on the second, navigate to false record of `stock.picking` by taking the id of `mrp.produciton` as the reserve is having `_name: "mrp.production"` **Screenshots from UI:** - Product page: <img width="1253" height="572" alt="stock_1" src="https://github.com/user-attachments/assets/13cd7f0a-34b0-48ea-a8d5-5337cbf9f5a5" /> - Forecasted report for that product: <img width="1908" height="994" alt="stock_2" src="https://github.com/user-attachments/assets/ce0af8a3-9f37-469c-8119-36b6e7be9c4a" /> - Clicking on First `WH/MO/00001` button: <img width="1265" height="568" alt="stock_3" src="https://github.com/user-attachments/assets/a8cb8a08-5c24-45f7-ad2e-5e3987f9ee70" /> - Clicking on second `WH/MO/00001` button, navigating to incorrect `stock.picking` by taking id of `mrp.production` even though there is no picking avaiable: <img width="1264" height="519" alt="stock_4" src="https://github.com/user-attachments/assets/3a2d1613-ccbb-4994-898c-c885690c507e" /> **Final view Before and After the Fix:** - For final view, In order to check the reservation done by `stock.picking`, I have created a `sale.order` having delivery for the same product to showcase both of them are working. - **Before Fix:** <img width="1907" height="994" alt="stock_5" src="https://github.com/user-attachments/assets/4441910e-348b-4270-ab1b-db903b334c97" /> - **After Fix:** <img width="1905" height="940" alt="stock_66" src="https://github.com/user-attachments/assets/ba288e6b-b2c9-47ed-b752-233ff876fb55" /> opw-[5481220](https://www.odoo.com/odoo/70/tasks/5481220?debug=1) upg-[3804157](https://upgrade.odoo.com/odoo/upgrade.request/3804157?debug=1) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244222