Odoo Changelog — 2024-09-04

Wednesday, September 4, 2024

6 changes · 17.0

Bug Fixes(6)

Resolved issues and error corrections

[FIX] iot: fix page reload issue

Enterprise17.0iotMEDIUM

A previously removed method that handles page reloading in the IoT module was causing errors for users with older interface versions. This fix restores the method to ensure compatibility and prevent system errors when users interact with IoT device setup.

Original PR description

We removed the `reload_page` method [here](https://github.com/odoo/enterprise/pull/68394/files#diff-ccc5eed84ca6b725960d95f2ab8b48188d5a078ab60a0a7c6c8ff7aeb29eddd9).  
Since, clients non-updated views still call it, but get a traceback as it doesn't exist anymore.

We then add it again to fix the issue.

Support task: 4152608

#compatibility#bug fix#IoT devices

[FIX] sale_subscription: consolidate billing by invoice address

PR #69277

Enterprise17.0sale_subscriptionMEDIUM

This fix resolves an issue where subscriptions with the same invoice address were being billed separately instead of consolidated into a single invoice. The system now correctly groups subscriptions by their invoice address before generating invoices, ensuring that customers with multiple subscriptions to the same billing location receive one combined invoice instead of multiple separate ones.

Original PR description

Steps to reproduce:
- Settings > Enable 'Consolidate subscriptions billing'
- Contact > Create a company
- Contacts & Addresses tab > Add
- Add an invoice address on the company
- Add an individual then duplicate it
- Create a subscription with the indiviual as customer
- Duplicate the subscription then set the duplicate contact as customer
- Debug mode > Scheduled actions
- Sale subscription: Generate recurring invoices and payments > Run manually

The subsciptions are invoiced separately instead of having one invoice
for both. The consolidated billing should produce only one invoice since
the invoicing address is the same.

This behavior works as intended if using the create invoices action on both
subscriptions at once. Here, the recurring invoice creation for subscriptions
uses its own grouping function using partner_id as a key instead of
partner_invoice_id which is 'parent invoice address id if any, else partner_id'.

Because this grouping is performed before creating the invoices, we end
up processing sale orders that should have belonged to the same group
separarately and thus create the invoices one by one. This means we
don't let _create_invoices do the grouping since we only pass it one SO
at a time, this fix will make it so _create_invoices is called on the
grouped SOs instead.

opw-4114035

#billing#consolidation#invoicing#subscriptions

[FIX] account_reports: Changed close function to a custom one

PR #69263

Enterprise17.0account_reportsMEDIUM

A dialog in the Account Reports module was failing to close properly due to a missing close function. This fix implements a custom close function that properly handles the dialog closure, allowing users to successfully open and close dialogs without encountering errors.

Original PR description

When we tried to open the dialog, we would get an error telling us that the function close from the props is missing.

The fix is to use a custom close function that will trigger the action of type `act_window_close`

task-4154392

#dialog#user-interface#bug-fix

[FIX] industry_fsm_sale : Avoid modifying invoice_status after invoicing SO

PR #68893

Enterprise17.0industry_fsm_saleMEDIUM

This fix prevents the invoice status of a sales order from incorrectly reverting from "Fully Invoiced" to "Nothing to Invoice" when a field service product's price is changed to zero after invoicing. The system now checks whether an order has already been invoiced before recalculating invoice status, ensuring the invoice history remains accurate and unchanged.

Original PR description

### Steps to reproduce: - Install Sale and Field Service modules - Create a Quotation with a normal product and another Field service product - Confirm the quotation and invoice it - Change the…

### Steps to reproduce:
	- Install Sale and Field Service modules
	- Create a Quotation with a normal product and another Field service product
	- Confirm the quotation and invoice it
	- Change the delivered quantity of the field service product to meet the order quantity
	- Check the invoice status (will be 'Fully Invoiced')
	- Set the field service product in the SO to a unit price 0

### Current behavior before PR:
After creating an invoice for a SO that has field service product and then set the product's unit price to 0 the SO invoice_status will change from 'Fully invoiced' to 'Nothing to invoice'. This is happening because in FSM we don't invoice SOL that has price_unit equals 0 which will lead that the SO inovice status will change too to 'Nothing to invoice'. https://github.com/odoo/enterprise/blob/17.0/industry_fsm_sale/models/sale_order.py#L84:L91

### Desired behavior after PR is merged:
We are now checking before computing the invoice status of any FSM product if the SO is not yet invoiced because if it is we won't modify the invoice status of the SOL.

opw-4017282

#invoice#field-service#sales-order#data-integrity

[FW][FIX] industry_fsm_sale: modify the so item domain

PR #69370

Enterprise17.0industry_fsm_saleMEDIUM

This fix corrects an issue where the sales order item list in field service tasks was incorrectly displaying down payments and loyalty rewards. The solution refines the filtering logic to show only relevant sales order items, improving accuracy when creating tasks for customer service requests.

Original PR description

Steps to reproduce the bug:
1. Install the Sales and Loyalty apps.
2. Create a sales order for 'client x' and assign a loyalty reward to it.
3. Invoice the sales order with a down payment.
4. Navigate to the Helpdesk app and create a ticket for 'client x'.
5. Create a task for the ticket and check the Sales order item list.

Issue:
The sales order item list incorrectly includes down payments and loyalty rewards due to an imprecise domain.

Solution:
Adding a domain function that we can override computed field where it's necessary, to filter the sale_order_line records
accurately.

opw-4001226

odoo pr : https://github.com/odoo/odoo/pull/173667

Forward-Port-Of: odoo/enterprise#66388

#field-service#sales-orders#data-filtering

[FIX] website_sale_subscription: allow add cart for variants recurrences

PR #69288

Enterprise17.0website_sale_subscriptionMEDIUM

This fix resolves an issue where customers couldn't add certain product variants to their cart when the product had multiple subscription plans. The system now correctly recognizes when a variant matches any of the subscription plans already in the cart, allowing the purchase to proceed instead of showing a compatibility error.

Original PR description

Steps
-----
[website_sale_subscription]
1. Create a recurring product with 2 recurring plans.
2. Create 2 variants for this product.
3. In the "Recurring Prices" tab, add a variant to the first plan and the other variant to the other plan.
4. Go to eCommerce and add to the cart the second variant (not the default selected one, this is important).
5. Refresh the page > ** This product pricing is not compatible with the product(s) in your cart. **

Cause
-----
`_get_first_suitable_recurring_pricing` doesn't specify a plan, so it can return a pricing which doesn't match the cart's plan.

Change
-----
Allow adding to the cart if any of the product's variants are matching the cart's plan.

opw-4081043

#subscription#ecommerce#product-variants#cart#bug-fix

We removed the `reload_page` method [here](https://github.com/odoo/enterprise/pull/68394/files#diff-ccc5eed84ca6b725960d95f2ab8b48188d5a078ab60a0a7c6c8ff7aeb29eddd9). Since, clients non-updated views still call it, but get a traceback as it doesn't exist anymore. We then add it again to fix the issue. Support task: 4152608

Steps to reproduce: - Settings > Enable 'Consolidate subscriptions billing' - Contact > Create a company - Contacts & Addresses tab > Add - Add an invoice address on the company - Add an individual then duplicate it - Create a subscription with the indiviual as customer - Duplicate the subscription then set the duplicate contact as customer - Debug mode > Scheduled actions - Sale subscription: Generate recurring invoices and payments > Run manually The subsciptions are invoiced separately instead of having one invoice for both. The consolidated billing should produce only one invoice since the invoicing address is the same. This behavior works as intended if using the create invoices action on both subscriptions at once. Here, the recurring invoice creation for subscriptions uses its own grouping function using partner_id as a key instead of partner_invoice_id which is 'parent invoice address id if any, else partner_id'. Because this grouping is performed before creating the invoices, we end up processing sale orders that should have belonged to the same group separarately and thus create the invoices one by one. This means we don't let _create_invoices do the grouping since we only pass it one SO at a time, this fix will make it so _create_invoices is called on the grouped SOs instead. opw-4114035

When we tried to open the dialog, we would get an error telling us that the function close from the props is missing. The fix is to use a custom close function that will trigger the action of type `act_window_close` task-4154392

### Steps to reproduce: - Install Sale and Field Service modules - Create a Quotation with a normal product and another Field service product - Confirm the quotation and invoice it - Change the delivered quantity of the field service product to meet the order quantity - Check the invoice status (will be 'Fully Invoiced') - Set the field service product in the SO to a unit price 0 ### Current behavior before PR: After creating an invoice for a SO that has field service product and then set the product's unit price to 0 the SO invoice_status will change from 'Fully invoiced' to 'Nothing to invoice'. This is happening because in FSM we don't invoice SOL that has price_unit equals 0 which will lead that the SO inovice status will change too to 'Nothing to invoice'. https://github.com/odoo/enterprise/blob/17.0/industry_fsm_sale/models/sale_order.py#L84:L91 ### Desired behavior after PR is merged: We are now checking before computing the invoice status of any FSM product if the SO is not yet invoiced because if it is we won't modify the invoice status of the SOL. opw-4017282

Steps to reproduce the bug: 1. Install the Sales and Loyalty apps. 2. Create a sales order for 'client x' and assign a loyalty reward to it. 3. Invoice the sales order with a down payment. 4. Navigate to the Helpdesk app and create a ticket for 'client x'. 5. Create a task for the ticket and check the Sales order item list. Issue: The sales order item list incorrectly includes down payments and loyalty rewards due to an imprecise domain. Solution: Adding a domain function that we can override computed field where it's necessary, to filter the sale_order_line records accurately. opw-4001226 odoo pr : https://github.com/odoo/odoo/pull/173667 Forward-Port-Of: odoo/enterprise#66388

Steps ----- [website_sale_subscription] 1. Create a recurring product with 2 recurring plans. 2. Create 2 variants for this product. 3. In the "Recurring Prices" tab, add a variant to the first plan and the other variant to the other plan. 4. Go to eCommerce and add to the cart the second variant (not the default selected one, this is important). 5. Refresh the page > ** This product pricing is not compatible with the product(s) in your cart. ** Cause ----- `_get_first_suitable_recurring_pricing` doesn't specify a plan, so it can return a pricing which doesn't match the cart's plan. Change ----- Allow adding to the cart if any of the product's variants are matching the cart's plan. opw-4081043