Monday, March 17, 2025
11 changes · 17.0
Resolved issues and error corrections
This fix prevents an internal error when the same grouping option is used more than once in data summaries. It helps keep grouped reports and calculations reliable instead of failing unexpectedly in this edge case.
Original PR description
Since https://github.com/odoo/odoo/pull/103510 , _read_group raises a StopIteration error if there are duplicate groupby specifications. This is because `groupby_terms` has become a `dict` which doesn't allow duplication but we are still looping on the `groupby` list to retrieve columns, leading to raise a StopIteration error when we try to retrieve the last column. Fix this by creating `groupby_terms` with `groupby` instead of values from the dict.
The Discuss call interface now shows connection warning icons only when appropriate. This removes a misleading warning from the user's own call card in small calls and restores the intended warning behavior when using server-based calls.
Original PR description
Before this commit, when making or joining a discuss call with up to 2 participants, it was always showing a warning icon in the top-right corner of the self card. This happened because the code to…
Before this commit, when making or joining a discuss call with up to 2 participants, it was always showing a warning icon in the top-right corner of the self card. This happened because the code to show connection issue on card filters on self session: warning icon on other sessions in P2P, and on self card when using SFU server. This was using `rtc.selfSession` to compare sessions, but this is correct only starting from 17.4. In 17.0, the `selfSession` is stored in `rtc.state.selfSession`. Because of this typo, the warning icon is always displayed on self card in P2P. This commit fixes the issue by using `rtc.state.selfSession`. Note that SFU branching for conditionally showing the icon was also wrong. This made it never show the triangle warning icon. This is also fixed by this commit. Before <img width="2261" alt="Screenshot 2025-03-17 at 11 36 07" src="https://github.com/user-attachments/assets/b11272b2-df95-4470-b9e5-ec6bd643b153" /> After <img width="2265" alt="Screenshot 2025-03-17 at 11 36 32" src="https://github.com/user-attachments/assets/f00a4978-d8cd-4201-a629-02618e71f381" />
Manufacturing orders now stay linked to their component stock movements even when components were not available for reservation. This makes the Moves History report more reliable when users filter by manufacturing order.
Original PR description
When producing a MO with components and the components don't have any available quantity, there are no direct link between the MO and the stock move lines of its move_raw_ids. This causes issues when filtering on MO in the Moves History report. This is because the link is only done at the reservation of the SMLs, which can't happen without available qty. This fix ensures that the MO is added at the SML creation. opw-4545828 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The online shop cart now correctly records when the final item has been removed. This prevents customers from seeing an unnecessary confirmation message when reordering from their portal after their cart is empty.
Original PR description
Steps: - Install Ecommerce - Add some products to the cart - Remove them using the 'remove' option - Go to my/orders - select any order, then click on Order again - Click on the Add To Cart button - You'll see one confirmation dialog Issue: - By clicking on the add to cart button, that confirmation dialog should not be there as the cart is empty Cause: - Cart quantity does not update when the last product is removed Fix: - While removing the last product, set cart quantity in sessionstorage to ensure that the last removal is recorded affected version-17.0 opw-4566505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The mail call interface now stops showing who is speaking when a user has deafened themselves. This prevents distracting or irrelevant call activity indicators for users who have chosen not to hear the conversation.
Original PR description
Current behavior before PR: `isTalking` status displayed who was talking even when the user had deafened themselves. Desired behavior after PR is merged: `isTalking` status no longer shows who is talking if the user has deafened themselves. Task-id:[4609755](https://www.odoo.com/odoo/project.task/4609755) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Currently if a user has "Read-Only" access in Accounting and any level of access in Timesheets (even "All Documents"), they won’t be able to export journal item analytical lines. This is inconsistent, as having more access in Timesheets should not restrict access in Accounting. Steps to Reproduce: - Create an invoice with analytic distribution. - Go to Journal Items. - Export the journal item, including analytic lines fields Issue: The user will not be able to export the data from thes
Original PR description
Currently if a user has "Read-Only" access in Accounting and any level of access in Timesheets (even "All Documents"), they won’t be able to export journal item analytical lines. This is…
Currently if a user has "Read-Only" access in Accounting and any level of access in Timesheets (even "All Documents"), they won’t be able to export journal item analytical lines. This is inconsistent, as having more access in Timesheets should not restrict access in Accounting. Steps to Reproduce: - Create an invoice with analytic distribution. - Go to Journal Items. - Export the journal item, including analytic lines fields Issue: The user will not be able to export the data from these fields. It occurs because timesheet users are restricted by ir-rules that allows access only to users owning the record or associated with a related project/task https://github.com/odoo/odoo/blob/34947c01623a9fc753197bd55d6121d9c6fa682f/addons/hr_timesheet/security/hr_timesheet_security.xml#L52 Solution is to add an ir-rule in account to allow read access to read-only users Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4586096) opw-4586096 Forward-Port-Of: odoo/odoo#201365
When manually adding a byproduct to a MO, the warehouse is not set because `default_warehouse_id` is missing from the context. This means that the push move from post-prod to stock is never created and the byproduct is stuck in post-production location. This fix adds the context key in the MO form view. Steps: - Activate routes & by-product in the main settings - Activate manufacturing in 3 steps on the warehouse - Create manufacturing order for a product and add a by-product with a positi
Original PR description
When manually adding a byproduct to a MO, the warehouse is not set because `default_warehouse_id` is missing from the context. This means that the push move from post-prod to stock is never created and the byproduct is stuck in post-production location. This fix adds the context key in the MO form view. Steps: - Activate routes & by-product in the main settings - Activate manufacturing in 3 steps on the warehouse - Create manufacturing order for a product and add a by-product with a positive quantity - Confirm manufacturing order - Pick components - Produce & close MO opw-4620008 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201619
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201966
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201966
Steps to reproduce: - Install the Website. - Enter edit mode. - Click on the "Add to Cart Button" snippet in the snippet menu. - Bug: The message displayed in the dialog is "Do you want to install the Add to Cart Button app?". This is incorrect; the app name should be the module name instead of the snippet name. This commit displays the module name as expected and slightly enhances the design of the dialog (line break before the link + add an arrow icon before the link to the app info).
Original PR description
Steps to reproduce: - Install the Website. - Enter edit mode. - Click on the "Add to Cart Button" snippet in the snippet menu. - Bug: The message displayed in the dialog is "Do you want to install the Add to Cart Button app?". This is incorrect; the app name should be the module name instead of the snippet name. This commit displays the module name as expected and slightly enhances the design of the dialog (line break before the link + add an arrow icon before the link to the app info). #### Preview | Before | |--------| |  | | After | |--------| |  | task-4434981 Forward-Port-Of: odoo/odoo#201757
When creating a partner with an italian VAT number in the backend, the field Codice Fiscale is automatically computed from the Tax ID. However, when a partner is created from the eCommerce of an italian company and the partner's VAT is filled, the Codice Fiscale is not filled in the newly created partner. This commit extends `values_preprocessing()` to compute the Codice Fiscale when the VAT field is filled (and starts with 'IT' or the country selected is Italy). Task [link](https://www.od
Original PR description
When creating a partner with an italian VAT number in the backend, the field Codice Fiscale is automatically computed from the Tax ID. However, when a partner is created from the eCommerce of an italian company and the partner's VAT is filled, the Codice Fiscale is not filled in the newly created partner. This commit extends `values_preprocessing()` to compute the Codice Fiscale when the VAT field is filled (and starts with 'IT' or the country selected is Italy). Task [link](https://www.odoo.com/odoo/project/967/tasks/4596227) task-4596227 Forward-Port-Of: odoo/odoo#199876
Issue ===== When product's code is computed, which is depend of the product's suppliers since each supplier can have a specific code, the first supplier is taken regardless if this supplier info is specific to another product variant which can cause to use the wrong code if there is multiple supplier with the same vendor but for different variants of the same product template. How to reproduce ================ 1. Install Puchase and Barcode; 2. Create a product with at least 2 variants;
Original PR description
Issue ===== When product's code is computed, which is depend of the product's suppliers since each supplier can have a specific code, the first supplier is taken regardless if this supplier info is…
Issue ===== When product's code is computed, which is depend of the product's suppliers since each supplier can have a specific code, the first supplier is taken regardless if this supplier info is specific to another product variant which can cause to use the wrong code if there is multiple supplier with the same vendor but for different variants of the same product template. How to reproduce ================ 1. Install Puchase and Barcode; 2. Create a product with at least 2 variants; 3. In the "Purchase" tab of this product, add two vendor pricelists with the same vendor but each for a different product variant and each with a different code; 4. Go in Purchase, create a new RFQ for this vendor, add a PO line for each variant and confirm the order; 5. Go in Barcode and open the PO's receipt -> You can see both lines have the same vendor's code (from the first pricelist) regardless the pricelist's product variant. Cause of the issue ================== In `_compute_product_code`, it uses the first product (template) supplier info regardless the product variant. Solution ======== In `_compute_product_code`, we skip a supplier info if it concerns another variant, and we break the supplier info loop only if it concerns the current product variant. Miscellaneous ============= The check of the `product.supplierinfo` `read` access right is moved outside of the loop so it is done only one time. [OPW-4589073](https://www.odoo.com/odoo/project/49/tasks/4589073) Forward-Port-Of: odoo/odoo#201753