Daily updates from Odoo
Monday, June 16, 2025
13 changes
2 changes
Resolved issues and error corrections
Employee managers can now create appraisal campaigns for their own team members even if they do not have broader appraisal access rights. The Launch Campaign button is shown only to managers, helping teams start reviews without needing extra administrative permissions.
Original PR description
Currently, employees managers with no access rights are not allowed to create a new appraisal concern for their employees. To grant managers the access to create appraisal campaigns, new customized access rule for employees' managers has been created. Also, both the Kanban and List views have been modified so that only the managers can see the "Launch Campaign" button.
This fixes an issue where people signing a shared document link in a private or public session could not complete the signing flow. The change ensures the system can retrieve the needed signing access details, preventing silent failures and server access errors.
Original PR description
To reproduce: - As demo user, create a new sign template - Get the share url and open it in a new private window - Fill the document fields - Click on 'Validate and Send Complete Document' * enter your name and email * click on `Validate and Send` button Here nothing happen, while on server side an `AccessError` is loggued. Since https://github.com/odoo/odoo/pull/201565 we need to get new request item access_token as superuser (user who created the template might not the sufficient rights to access it)
11 changes
Resolved issues and error corrections
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-4809095Delivery 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 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
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-4809095Portal 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
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