Monday, June 16, 2025
19 changes · 18.0
Resolved issues and error corrections
Some mail conversation data can occasionally reference a participant whose contact profile is no longer available in the browser. This fix skips those incomplete entries when identifying the conversation counterpart, preventing unnecessary crashes and keeping messaging usable.
Original PR description
There are several flows where the persona of a member might not (or no longer) be known in JS. These members should simply be ignored when computing the correspondent of a channel rather than crashing.
Reversed point-of-sale orders in the Indian localization now receive the correct place of supply information. This helps ensure tax and compliance details remain complete when POS orders are reversed.
Original PR description
Before this commit: - The `_compute_l10n_in_state_id` method only considered `pos_session_ids` when assigning the state for Indian POS moves. - Reversed POS orders were ignored, leading to missing `l10n_in_state_id`. After this commit: - Added `reversed_pos_order_id` to the `@api.depends` decorator. - Updated domain to include moves with `reversed_pos_order_id`. Ensures correct place of supply is computed for reversed POS orders as well. OPW: 4862639
The website mega menu now shows as a single-column layout when using sidebar or hamburger header styles, preventing broken navigation displays. The menu size setting is also hidden for these header styles because it does not apply, making configuration clearer for website editors.
Original PR description
Steps to reproduce: - Enter website edit mode. - Click the header. - Select "Sidebar" in the template options. - Save the page. - Click Site > Menu Editor in the backend navbar. - Add a "Mega menu" to the menu and save the dialog. - In the sidebar, open the "Mega menu". - Bug: The layout is broken. The mega menu should be displayed in a single column, but it's displayed in three columns. In this commit, we fix the issue by forcing the columns width of the mega menu to 100% when the header is set to "Sidebar" or "Hamburger". This commit also hides the "Size" option of the mega menu when the header template is set to "hamburger" or "sidebar", as it has no effect with either of these headers. task-4830118
Manufacturing orders now keep components in the intended bill of materials order when a kit is included. This prevents confusing or incorrect component move sequencing, making production lists match how products were defined.
Original PR description
When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM. Steps to reproduce: - Create a product P1…
When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM.
Steps to reproduce:
- Create a product P1 with a BoM that includes:
- Component 1 (sequence = 1)
- Component 2 - KIT (sequence = 2), which itself contains:
- Component 2-1 (sequence = 1)
- Component 2-2 (sequence = 2)
- Component 3 (sequence = 3)
- Create a Manufacturing Order for P1.
Observed behavior:
- The generated stock moves are ordered as:
1. Component 1
2. Component 3
3. Component 2-1
4. Component 2-2
Expected behavior:
- The stock moves should respect the BoM line sequence:
1. Component 1
2. Component 2-1
3. Component 2-2
4. Component 3
Root cause:
- When exploding phantom BoMs, child lines were appended at the end of the processing queue, causing out-of-order moves:
https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L416-L418
https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L430
Solution:
- Insert the child BoM lines at the beginning of the processing queue (`bom_lines`), sorted by their sequence field, to ensure correct processing order.
opw-4809095This fix makes an automated website event test wait until editing is properly finished before moving on. It reduces random test failures caused by timing differences, helping keep quality checks stable without changing customer-facing behavior.
Original PR description
The test `test_website_event_tour_admin` fails randomly depending on the processing speed available. When clicking on `a[title='Back to All Events']`, if the website happens to still be in edit mode, the click will be prevented: https://github.com/odoo/odoo/blob/18.0/addons/website/static/src/client_actions/website_preview/website_preview.js#L424-L438 We can use the clickOnSave function made specifically for this. It ensures exiting edit mode before continuing. --- runbot-223022
Delivery options that require product tags are now shown when an order contains at least one product with one of the required tags. This prevents valid shipping methods from disappearing at checkout and helps customers complete purchases more reliably.
Original PR description
Versions -------- - 18.0+ Feature doesn't exist in earlier versions. Steps ----- 1. Create a product with a tag; 2. create another product with a different tag; 3. create a delivery method with these 2 tags as Must Have Tags; 4. add one product to the cart in eCommerce; 5. go to checkout. Issue ----- Delivery method isn't available for selection. Cause ----- While the "Must Have Tags" description states that the method should be available if at least one product on the order has at least one of these tags, the `_match_must_have_tags` method requires *all* of the `must_have_tags` to be present in the order. Solution -------- Instead of using `all`, use `any` when matching must-have tags. opw-4836137
Customers can now reorder bundled combo products from the portal without the bundle being split into separate items. The reorder window also shows availability for the full combo, helping customers understand whether the bundled product can be fulfilled.
Original PR description
Steps to Reproduce: - Install `website_sale_stock` and enable the Reorder from portal feature. - Place an order from `/shop` that includes one or more combo products. - Navigate to `/my/orders` and…
Steps to Reproduce: - Install `website_sale_stock` and enable the Reorder from portal feature. - Place an order from `/shop` that includes one or more combo products. - Navigate to `/my/orders` and attempt to reorder the same. - Combo products are broken into separate lines rather than shown as a single combo. - Stock information for the combo is not available, as the items are treated independently. Issue: - Combo products are displayed as separate lines in reorder modal - Also stock management of combo products is not there Cause: - The `/my/orders/reorder_modal_content` controller route lacks logic to handle combo products. The reorder modal builds the cart lines assuming all items are standalone, disregarding combo grouping and related stock aggregation. Solution: - Extend the `/my/orders/reorder_modal_content` route logic to correctly identify and process combo products as single bundled entities. - Update the reorder modal in `website_sale_stock` to incorporate combo-specific stock handling, ensuring accurate availability feedback for the entire combo. - This ensures that the reorder experience mirrors the original order composition and improves stock visibility for bundled products. opw-4731014 Affected Version-18.0
This fix prevents errors when an invoice line is linked to multiple sales order lines. It uses the analytic distribution from the first linked sales line so invoice creation can continue reliably.
Original PR description
In odoo/odoo#199763, `_related_analytic_distribution()` was introduced to pass the existing analytic distribution in a sale order line to an invoice line. However, sale_line_ids is a Many2Many field, so to avoid singleton errors in the case of multiple SOLs, only the analytic distribution of the first sale order line is passed. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a crash when users group a pivot view by a custom task property and insert it into a spreadsheet. The spreadsheet now loads the needed property details so the pivot can open correctly, improving reliability for reporting workflows.
Original PR description
Steps to reproduce: - add a property on Tasks - open a pivot view - group by this property - insert in spreadsheet => boom The pivot cannot be loaded because the property is not a real field. Hence it's not loaded by `fields_get` and we are missing the property metadata (type) We need to load the definition independently and we push it to the fields. It's a hack but it seems to work. opw-4858129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a problem where product images added through the website editor could not be adjusted later with the image editing tools. Store teams can now resize or modify those images directly in the website editor, improving product page maintenance.
Original PR description
**Steps to reproduce:** - Install eCommerce app - Go to the shop of the website - Activate the editor - Click on 'New' in the top right - Create new product with image - Image is automatically converted to 1920x1920 (unless given in webp format) - Try to edit the product image later on - The ImageTools editor options are not available **Issue:** When using the `New` -> `Product` flow of the website editor, the user can't modify the given image, and as the image tools are disabled it can't manually do it when the product is saved. **Fix:** Added necessary fields to the html element of the product image when computing `'ir.qweb.field.image'` so that it can be processed like the other images created with building blocks. To achieve this, the original image file related to the current product image needs to be fetched. opw-4561958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures combo product choices are checked for company compatibility even when existing combo items were not edited directly. It prevents users from saving product combinations that could later cause multi-company errors or inconsistent product availability.
Original PR description
to_reproduce: --- 1. Create a combo product (no company set) 2. Create a combo choice (no company set) 3. Add a product with company restrictions 4. Multi-company error appears: "Incompatible…
to_reproduce: --- 1. Create a combo product (no company set) 2. Create a combo choice (no company set) 3. Add a product with company restrictions 4. Multi-company error appears: "Incompatible companies on records" 5. Set company on combo choice and product template - error resolves 6. Remove company from both combo choice and combo product template 7. Save succeeds despite invalid company configuration problem: --- - During combo choice updates, only the modified combo items are included in vals['combo_item_ids'], while existing unchanged combo items are not added to the validation scope. https://github.com/odoo/odoo/blob/b13c686dbd6a887a251143efca1c18e7a4fb631a/addons/web/models/models.py#L68 - The company validation logic only checks items present in the vals, missing the existing combo items that should also be validated for company consistency. https://github.com/odoo/odoo/blob/b13c686dbd6a887a251143efca1c18e7a4fb631a/addons/web/models/models.py#L1092 solution: --- - Add another check on combo items opw-4844678 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The account type `Caixa` (Cash) and `Depósitos à Ordem` (Demand deposits) were missing from the Portuguese localization. Changed translations in pt.po for the template_chart.py context. Steps to reproduce: - install the accountant and l10n_pt module. - select a Portuguese company. - in the Chart of Accounts, notice there is no account named `Caixa` and `Depósitos à ordem`. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4829413) opw-4829413
Original PR description
The account type `Caixa` (Cash) and `Depósitos à Ordem` (Demand deposits) were missing from the Portuguese localization. Changed translations in pt.po for the template_chart.py context. Steps to reproduce: - install the accountant and l10n_pt module. - select a Portuguese company. - in the Chart of Accounts, notice there is no account named `Caixa` and `Depósitos à ordem`. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4829413) opw-4829413
This fix makes work order duration calculations ignore tiny microsecond differences when recording productivity time. It prevents occasional test and rounding failures caused by insignificant timing fluctuations, improving reliability without changing business workflows.
Original PR description
The `_set_duration` inverse method of `mrp.workorder` is ignoring microsecond variations when computing the `date_start` of a workorder productivity record. This method uses the current time as the end date but does not remove microseconds from it. This causes a intermittent error when running the `test_labor_cost_balancing_with_cost_share`, because the computed duration (around 0.03 hours or 1.8 seconds) can vary slightly depending on the microseconds captured by `datetime.now()`. This fluctuation results in a 1- or 2-second difference, which breaks the test. To fix it, we simply set the microsseconds of the end date to zero. This bug was introduced in: https://github.com/odoo/odoo/pull/80319/commits/15fef27edb3ec437d1dbec33481c5d778795bc59 Runbot failure example: https://runbot.odoo.com/odoo/runbot.build.error/226657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users with approved temporary lock date exceptions can now reset tax closing entries for covered periods without being incorrectly blocked. The change also applies the correct lock rules, including stricter hard locks and parent company lock dates, helping finance teams avoid unnecessary disruption while preserving controls.
Original PR description
Current behavior before commit: When resetting a closing entry from a tax-locked period, the system raises a lock date error, even if the user has a temporary lock date exception allowing them to…
Current behavior before commit: When resetting a closing entry from a tax-locked period, the system raises a lock date error, even if the user has a temporary lock date exception allowing them to bypass the restriction. Root Cause: The method only checks the company's permanent tax_lock_date, without considering temporary user-level exceptions. As a result, even if an exception is granted, the system still raises a lock error based on the permanent date. Additionally, the hard lock date (which overrides all other lock types and doesnt allow exceptions) and parent company lock date are ignored. Fix: Replaced the direct lock date check with _get_lock_date_violations(), which: - Correctly considers user-specific temporary lock date exceptions. - Returns violations based on effective lock rules (including hard lock). - Provides a more generic error message. Steps to reproduce: - Use a tax report with carryover values (e.g. Belgian VAT return, line 81). - Post a refund using a tax that maps to the carryover (e.g. 21% M). - Generate a closing entry. - Set the company’s tax_lock_date to a date covering the refund. - Grant a temporary lock date exception to the user, covering the same date. - Try to reset the closing entry → Lock date error is raised (incorrectly). opw-4715100
Manufacturing orders now list components from kit-style bills of materials in the same order defined by the business. This prevents component lists from appearing out of sequence, making production preparation clearer and less error-prone.
Original PR description
When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM. Steps to reproduce: - Create a product P1…
When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM.
Steps to reproduce:
- Create a product P1 with a BoM that includes:
- Component 1 (sequence = 1)
- Component 2 - KIT (sequence = 2), which itself contains:
- Component 2-1 (sequence = 1)
- Component 2-2 (sequence = 2)
- Component 3 (sequence = 3)
- Create a Manufacturing Order for P1.
Observed behavior:
- The generated stock moves are ordered as:
1. Component 1
2. Component 3
3. Component 2-1
4. Component 2-2
Expected behavior:
- The stock moves should respect the BoM line sequence:
1. Component 1
2. Component 2-1
3. Component 2-2
4. Component 3
Root cause:
- When exploding phantom BoMs, child lines were appended at the end of the processing queue, causing out-of-order moves:
https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L416-L418
https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L430
Solution:
- Insert the child BoM lines at the beginning of the processing queue (`bom_lines`), sorted by their sequence field, to ensure correct processing order.
opw-4809095Users trying to fetch a Shopee shipping label for a delivery that is not connected to a Shopee shop will now see a clear error message instead of a technical crash. This helps staff understand what is wrong and prevents confusing system tracebacks during shipping operations.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”
- Create a delivery order with one unit of P1, not linked to any sale order
- Go to the delivery order list view
- Select the created delivery order
- Click on Action → Fetch shipping label
Problem:
A traceback is triggered:
```
ValueError: ValueError('Expected singleton: shopee.shop()') while
evaluating
'records._fetch_shipment_label()'
The above server error caused the following client error:
```
The `_fetch_shipment_label` function expects at least one item, but
we don't check it via a user error, because we're supposed to call
`_sync_shopee_pickings` instead, where all these filtering and checks
are done
opw-4812360Portal users using a shared project folder link can now upload documents without being blocked by an access error. This ensures external collaborators can contribute files as intended when upload permissions are granted.
Original PR description
To reproduce: ============= - install documents_project - create project - go to documents and get share link of the project's folder with permission to upload (anyone with the link can upload) - open the share link in a new browser window and connect as portal user - upload a document -> access error Problem: ======== while uploading a document, we will need to read `partner_id` from the linked project, but the portal user does not have access to the project Solution: ======== read as `sudo` opw-4782062
The Data Cleaning module now uses a unique identifier for its model form, preventing it from being overwritten during installation. This ensures the expected configuration screen is available and avoids missing setup options for users.
Original PR description
**Issue:** The data_cleaning module contains two views, data_merge_model_views and data_cleaning_model_views, that share the same form view id. **Steps to Reproduce:** 1. Install the data_cleaning…
**Issue:** The data_cleaning module contains two views, data_merge_model_views and data_cleaning_model_views, that share the same form view id. **Steps to Reproduce:** 1. Install the data_cleaning module 2. Open psql in the terminal 3. Run the following query:” select id, name, model from ir_ui_view where model ilike 'data_%' and type = 'form';” 4. Observe that data_cleaning.model is missing from the results Expected Behavior: the form view for data_cleaning.model should be present in the database. Actual Behavior: the form view for data_cleaning.model is not found in the database. **Root Cause** The form view in data_cleaning_model_views has the same id as the one in data_merge_model_views. Because data_cleaning_model_views is loaded first (as defined in __manifest__.py), it gets overwritten by data_merge_model_views. **Fix** To prevent this issue, the form view id in data_cleaning_model_views has been renamed to a unique and more appropriate identifier. Opw-4517418
This fixes an issue where uploading a file to a new document request could silently fail the first time. Users can now attach documents successfully on their initial upload attempt, reducing confusion and repeated work.
Original PR description
Steps to reproduce - install documents - create a document request from "New" menu - try to upload document for that request Observation: when trying to upload for the first time, nothing is…
Steps to reproduce - install documents - create a document request from "New" menu - try to upload document for that request Observation: when trying to upload for the first time, nothing is uploaded, second time, document is uploaded successfully Issue - when uploading file, a rpc is made to `get_document_max_upload_limit` method from `loadMaxUploadSize` https://github.com/odoo/enterprise/blob/c2785a89b06e90dbc31c711c7e1e637679fcb323/documents/static/src/core/document_service.js#L18-L20 - Due to this call, the files (FileList object) from previous request (original request) are lost and there is nothing left to upload. https://github.com/odoo/enterprise/blob/c2785a89b06e90dbc31c711c7e1e637679fcb323/documents/static/src/core/document_service.js#L375-L378 - On subsequent attempts, the maxUploadSize is memoized and no further RPC is made, so the issue does not reoccur. Fix - Clone the files array before making the loadMaxUploadSize() call to preserve the original file objects. opw-4725113