Daily updates from Odoo
Friday, April 3, 2026
7 changes · saas-18.2
Resolved issues and error corrections
This update corrects a bug where discounts were applied twice to service tasks, resulting in incorrect pricing. The fix ensures discounts are applied correctly based on sales order settings, preventing over-discounting and ensuring accurate pricing for service tasks. This improves the reliability of pricing calculations for field service operations.
Original PR description
Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service. <h2>Steps to produce:</h2> * Install `industry_fsm_sale` and enable…
Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service. <h2>Steps to produce:</h2> * Install `industry_fsm_sale` and enable `Discounts` and `Pricelists` in settings. * Create a pricelist with a price rule of type discount that applies 10 percent discount to every product. * Go to Customers > Acme Corporation > Sales & Purchase and set the pricelist. * Go to Field Service > Create a Task, and set `Customer` to Acme Corporation. * Add a timesheet with Time Spent 1 > Mark the task as Done > Sale Order <h2>Observed behavior:</h2> The discount is applied twice to the product on SO: **Product**: Service on Timesheets **Unit Price**: `$40` (excluding tax) **First discount:** The 10 percent discount on the unit price of the product. Product unit price is set from `$40 -> $36 ` **Second discount:** The 10 percent discount on the SO line itself. `$36 -> $32.4 ` The untaxed amount is: `$32.40` which should be `$36.00` <h2>Root cause:</h2> This happens because, at line [1], the unit price is already set to the final price from the pricelist when the sale order line is created. Since discounts are enabled, [2] applies an additional discount to that same price, causing the discount to be applied twice. <h2>Solution:</h2> When creating the sales order: * **Discount setting is on:** use list price so the discount is applied from the sales order. * **Discount setting is off:** set the product unit price to the discounted price. [1]- https://github.com/odoo/enterprise/blob/224d2453cc975a3e333825370beaf30d27d89f10/industry_fsm_sale/models/project_task.py#L658 [2]- https://github.com/odoo/odoo/blob/76717e588bfd012b42e859bfc829257d899c6165/addons/sale/models/sale_order_line.py#L788 opw-5432088 Forward-Port-Of: odoo/enterprise#103950
This update resolves an issue where the breadcrumb navigation within the Barcode app was displaying incorrect or blank entries when moving between related records. Now, the breadcrumb accurately reflects the originating document name, improving user clarity and ease of navigation.
Original PR description
*: stock_barcode_mrp, stock_barcode_picking_batch ## Issue Before This PR: When navigating from the Barcode client action (e.g. picking, inventory, etc.) to related form views (such as lot, product,…
*: stock_barcode_mrp, stock_barcode_picking_batch
## Issue Before This PR:
When navigating from the Barcode client action
(e.g. picking, inventory, etc.) to related form views
(such as lot, product, or company), the breadcrumb
would sometimes display an unnamed entry instead
of the originating document name.
This caused confusion for users, as they could not
easily identify which document they were coming from
when navigating to related records from the Barcode interface.
## Steps to Reproduce:
- Install the Barcode module.
- Open the Barcode app and navigate to:
- Delivery Orders.
- Manufacturing Orders
- Batch Pickings
- Inventory Count
- From any of these open a record
(e.g. picking, MO, batch, inventory line)
- Click on document name or edit button on the line.
- Click on an external link (e.g. product, lot, company).
- Observe that the breadcrumb shows an unnamed entry.
## Cause of the Issue:
- When switching views inside the Barcode client action,
the FormController calls `setDisplayName(this.displayName())`.
In some cases, this returns an empty string, overwriting the
previously set breadcrumb name.
- In several form views, the `display_name` field was not present,
preventing the controller from retrieving a proper name.
## With This PR:
The Barcode views now display the correct document names in the
breadcrumb when navigating to external links, allowing users to easily
identify the originating document when opening related records from
the Barcode app.
TaskID: 4978997This update fixes a bug that prevented users from viewing ticket analysis data when grouping by Employee, Manager, or Department. The fix maps reporting fields to the correct ticket fields, ensuring accurate data display and preventing server errors. This improves the reliability of the reporting feature.
Original PR description
Currently, an error occurs on clicking on the graph or the pivot cell if the data is grouped by Employee/Manager/Department. ### **Steps to reproduce** 1) Install helpdesk_timesheet with demo data 2)…
Currently, an error occurs on clicking on the graph or the pivot cell if the data is grouped by Employee/Manager/Department.
### **Steps to reproduce**
1) Install helpdesk_timesheet with demo data
2) Go to Timesheet > Reporting > Ticket Analysis
3) Set group by to Employee
4) Click on any graph bar or pivot cell
### **Error:**
`ValueError: Invalid field helpdesk.ticket.employee_id in condition ('employee_id', '=', 1)`
Root Cause:
The `helpdesk.ticket.report.analysis` model includes specific fields such as `employee_id`, `department_id`, and `employee_parent_id` (see [1]) that are defined for reporting purposes but do not exist on the `helpdesk.ticket` model. When a user clicks a data point to view related tickets, the reporting view passes the current domain directly to the ticket list view. Because `helpdesk.ticket` lacks these fields, the ORM fails to validate the domain, resulting in a server error.
[1]- https://github.com/odoo/enterprise/blob/8d16b647431985dd7c216ae39eea6ca050e04b46/helpdesk_timesheet/report/helpdesk_ticket_report_analysis.py#L15-L17
### **Fix:**
This commit introduces a mixin to intercept the openView call. The mixin maps reporting-specific fields to valid relational paths on the ticket model `(for example, employee_id is transformed into user_id.employee_id)`. This ensures that the domain generated from the report model is compatible with the target ticket model.
**opw-5931273**This update ensures that time off requests marked as 'refused' are clearly highlighted on the Gantt chart view in the Time Off Management section. Previously, these requests weren't visually distinguished, leading to potential confusion. This change improves clarity and accuracy for managing employee time off.
Original PR description
Before this commit, the gantt view in Management > Time off menu does not strike the time off refused. The reason is because the wrong js_class is used inside that view. This commit updates the js_class to use inside that view to make sure the time off refused are striked. Issue similar to https://github.com/odoo/odoo/issues/248868 Forward-Port-Of: odoo/enterprise#112441
This update corrects a bug in the Belgian payroll module that prevented time off requests for Laurie Poiret and Max Durand from being accurately reflected in payroll calculations. The fix ensures that the demo data uses the correct company calendar for these employees, resolving the issue and improving payroll reporting accuracy.
Original PR description
### Issue: Laurie Poiret has a calendar belonging to another company. This causes issues in the Payroll app. ### Steps to reproduce: - On runbot, switch to a Belgian company - Create a time off for Laurie Poiret, validate it - In Payroll > Work Entries you can see that the time off is not considered ### Cause: The `resource.calendar.leaves` of the time off belongs to another company, which prevents it from being fetched. This is because at its creation it takes the company of the given calendar. ### Solution: Fix the demo data so that Laurie Poiret has a calendar from the Belgian company. Same for Max Durand. opw-6053558 Forward-Port-Of: odoo/enterprise#112112
This update resolves an issue where the LPP (Labor Pension Plan) was incorrectly applied to employee salaries in the Swiss payroll module when employees were not insured. The fix ensures that LPP contributions are only applied to insured employees, aligning with Swiss tax regulations and improving payroll accuracy. This change impacts the correct calculation of employee benefits.
Original PR description
Forward-Port-Of: odoo/enterprise#112824
This update resolves an issue where the new IoT image wasn't correctly scaling due to a misinterpretation of device connectivity. The fix removes a redundant check in the scaling service, ensuring the IoT image functions seamlessly with the scaling process. This improves the overall stability and performance of the Enterprise edition.
Original PR description
The new IoT image removes the `hw_proxy/status_json` endpoint, which results in the hardware proxy service thinking there are no devices connected to the IoT. We now remove this check from the scale service so that the new image works correctly with a scale. Forward-Port-Of: odoo/enterprise#112941