Monday, December 1, 2025
12 changes · saas-18.4
Resolved issues and error corrections
This update fixes an issue where tasks created from sales order lines weren't automatically reflecting the correct number of hours. Previously, allocated hours were incorrectly set to zero for certain service products. This change ensures that the allocated hours on tasks are accurately set to match the quantity of the corresponding sales order line, improving the accuracy of time tracking.
Original PR description
To reproduce: ============= - Create service product with `service_tracking = task_in_project` and `service_type = manual` - Create a SO with this product and set quantity on the line - Confirm the SO - check the created task, allocated hours is 0.0 instead of the quantity of the SO line Problem: ======== When creating tasks from SO lines, allocated hours is initialized to 0 then computed based on the SOL quantity except when the product's service_type is 'milestones' or 'manual'. Solution: ========= Following the logic in `write` method of `sale.order.line`, the allocated hours should be set to the SOL quantity. opw-5153467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237398 Forward-Port-Of: odoo/odoo#234524
This update resolves an issue where the DIOT tax report export failed when journal entries lacked a linked partner. The fix ensures that the export process gracefully handles entries without partners, preventing errors and improving data reporting reliability. This change addresses a technical bug related to data processing within the DIOT reporting module.
Original PR description
**Steps to reproduce:** 1. Install `Accounting` and `l10n_mx_reports` modules. 2. Create two journal entries using DIOT tax grid: one with partner, one without 3. Confirm the entries. 4. Go to `Accounting → Reporting → Tax Report → DIOT (MX)`. 5. Try to print the DIOT report in TXT format from the top-right dropdown. **Observed behavior:** * Export fails with a traceback if any entry has no partner. **Root cause:** The method `_get_diot_values_per_partner` does not handle entries without partners. **Solution:** raise `Usererror` if entries without partners when sorting and exporting. note: The second commit addresses a traceback caused by a missing operation_type_code. This occurs when all entries lack a partner or when a partner’s operation_type_code field is not set. opw-5060825 Forward-Port-Of: odoo/enterprise#100843 Forward-Port-Of: odoo/enterprise#96529
This update prevents a critical error that occurred when employees without a working schedule attempted to view their time off in the Gantt view. The fix ensures the system gracefully handles missing schedule data, improving the user experience and preventing data display issues. This resolves a technical issue impacting time off reporting.
Original PR description
Currently, an error occurs when an employee has no working schedule set and the user tries to open the Time Off overview in the Gantt view. **Steps to Reproduce:** 1. Install `hr_holidays_gantt` with demo data. 2. Remove the **Working Hours**(Payroll section) of **Marc Demo**. 3. Navigate to: Time off > Overview. **Error:** `AttributeError - 'bool' object has no attribute 'upper'` **Cause:** The error occurs because at [1], the contract does not have a `resource_calendar_id` (working schedule) assigned. As a result, it attempts to access attributes of a False value, causing the error. **Fix:** This commit skips the computation when the contract does not have a working schedule set. [1] - https://github.com/odoo/enterprise/blob/db049f42ad4c2c291b2d64a9e637cd2292c280e8/hr_holidays_gantt/models/hr_leave.py#L204 sentry-7017326141
This update fixes a bug that caused video streams with background blur to freeze when users switched between browser tabs during video calls. By using a separate worker thread for frame scheduling, the system now maintains a consistent video stream, ensuring smooth and uninterrupted calls.
Original PR description
**Description of the issue/feature this PR addresses:** This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab…
**Description of the issue/feature this PR addresses:** This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab during video calls. **Current behavior before PR:** When background blur is enabled during a video call, the user’s video stream freezes if they switch to another browser tab. This happens because currently frame scheduling relies on `requestAnimationFrame` and `setTimeout`, which modern browsers pause or throttle in inactive tabs to conserve system resources and battery life. **Desired behavior after PR is merged:** The user’s video stream continues to render with the background blur effect, even when the browser tab is inactive. This is achieved by moving the frame scheduling logic to a Web Worker, which runs in a separate thread and is not subject to browser throttling. As a result, a consistent frame rate is maintained at all times. task-[4781227](https://www.odoo.com/odoo/project/1519/tasks/4781227) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226455
This update resolves an issue preventing proper access to key fields within the payroll module for Switzerland (l10n_ch_hr_payroll_elm_transmission_5_3). The fix ensures accurate data transmission related to Swiss payroll reporting, improving the reliability of financial reporting. This change impacts the HR and Payroll functionalities.
This update resolves an issue where the spreadsheet feature wasn't reliably displaying data errors, leading to a confusing user experience. The team removed a confusing 'clear' button and corrected a technical error that prevented data loading errors from being properly displayed. This ensures data is loaded correctly and errors are clearly communicated to the user.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236683 Forward-Port-Of: odoo/odoo#233739
This update resolves an issue where users creating filters in the spreadsheet edition would encounter errors when working with broken data sources. The fix extends a previous safeguard to all filter types, ensuring a smoother user experience and preventing crashes during filter creation, particularly after data source migrations.
Original PR description
Forward-Port-Of: odoo/enterprise#100027 Forward-Port-Of: odoo/enterprise#98448
This update fixes a previous limitation by allowing portal users to be directly linked to employee records within the HR module. The system now displays all portal users in the employee selection field and defaults the search view to show internal users, improving data accuracy and streamlining workflows. This change simplifies employee management and reporting.
Original PR description
- Display all portal users in the user field. - Set the default filter in the search view to show internal users. - Change the placeholder text for the `user_id`. task-5176046
This update fixes an issue where the invoice date was incorrectly changing after a company partner's address was updated. The fix ensures that the invoice date remains consistent, regardless of address changes, preventing potential accounting discrepancies. This improves data accuracy and reliability for Czech invoices.
Original PR description
**Steps to reproduce** 1.Install Accounting, Contacts, and l10n_cz. 2.Create an invoice with a future `invoice date` and confirm it. 3.Go to Contacts → open the company (res.partner). 4.Modify any…
**Steps to reproduce** 1.Install Accounting, Contacts, and l10n_cz. 2.Create an invoice with a future `invoice date` and confirm it. 3.Go to Contacts → open the company (res.partner). 4.Modify any address field (street, zip, etc.) and save. 5.Return to the invoice → in the chatter, the `date` field has change unexpectedly > Note: The `date` field is not shown in invoice default form view. Add it manually for clearer reproduction. **Issue** - The confirmed invoice `date` changes when updating the company partner’s address. **Cause** https://github.com/odoo/odoo/blob/7a1b27e5985b3b16768bea450c51226ae3659c76/addons/l10n_cz/models/account_move.py#L20-L24 - When creating an invoice, the `date` field is correctly set based on the `taxable_supply_date` while the invoice is in the draft state. After confirming (posting) the invoice, it moves to the `posted` state. - However, when updating the partner address, the `_compute_date` method is triggered again, which calls `super()` and recomputes the `date` field using the standard logic. Since the invoice is already in the `posted` state, the CZ-specific condition is not satisfied, and the `date` gets updated incorrectly. **Solution** - Update `_compute_date` to only call super() for invoices in draft state. - This prevents unwanted recomputation of the `date` on post invoices. opw - 5086961 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238045 Forward-Port-Of: odoo/odoo#229513
This update fixes a technical issue related to payroll processing in the Odoo Enterprise module for Switzerland (l10n_ch_hr_payroll). It adds missing input types required to accurately reflect Swiss tax and social security regulations, ensuring correct payroll calculations and compliance.
This update corrects a bug where credit notes weren't automatically generating deferred revenue entries. The system was incorrectly using a setting designed for invoices. Now, credit notes will correctly create deferred revenue entries when configured to 'On bill validation', ensuring accurate accounting for deferrals.
Original PR description
The system incorrectly uses the `Deferred Expense Entries` configuration to determine whether to create deferrals for credit notes, while it should follow the `Deferred Revenue Entries` setting, as invoices do. As a result, deferred entries for credit notes are not created when expected. Steps to reproduce: - Go to Accounting → Configuration → Settings. - In the Deferred Expense Entries section, set Generate entries to: Manually & Grouped - In the Deferred Revenue Entries section, set Generate entries to: On bill validation - Navigate to Accounting → Customers → Credit Notes. - Create a credit note with at least one line containing Date From and Date To (i.e., deferrable line). - Validate the credit note. - No deferred revenue entries are created. Ticket [link](https://www.odoo.com/odoo/project.task/5187051) opw-5187051 Forward-Port-Of: odoo/enterprise#100211
This update fixes a bug in the shop floor component consumption process when tracking by lot. Previously, the system incorrectly consumed large quantities (e.g., 1000kg instead of 50g) due to an issue with how lot quantities were handled. This change ensures accurate component consumption based on lot quantities, improving inventory management.
Original PR description
**PROBLEM** Component consumption behavior in shop floor is buggy when the component is tracked by lot. When "selecting" a lot to take from, the consumed amount is not correct. (ex, we ask for 50g,…
**PROBLEM** Component consumption behavior in shop floor is buggy when the component is tracked by lot. When "selecting" a lot to take from, the consumed amount is not correct. (ex, we ask for 50g, and it consumes 1000kg). **STEP TO REPRODUCE** 1. create a product. 2. create a bom with: - a component tracked by lot, with kg as product uom, but g as the bom uom. - create a step, during which 50g of the component is consumed. 3. create two lots of the component, with 1kg each. 4. create a MO for the product with the bom. 5. in the shop floor, try consuming the component and select one of the lot as a source. 6. the consumed amount should be 50g, remove the move line created (pencil icon, then remove). 7. recreate the move line, the consume amount will be nonsensical (something like 1 000 000g). **CAUSE** 1. The dialog opened for selecting the lot create a new `stock.quant` record, instead of returning the existing quant for the lot. This quant will have a quantity of 0, impacting the computation we do for the quantity we should take from this quant. 2. The formula for the quantity to take from the quant was : `max(min(remaining_qty, quant.available_quantity), 1)`. The `max(...,1)` doesn't work well when `remaining_qty` is between 0 and 1. For example, when using UoM like we do in the repro steps, `remaining_qty = 50g = 0.05kg`. But instead of taking 50g, because of the max we take 1kg = 1000g. 3. There was a double UoM conversion (`_prepare_move_line_vals` already does the conversion, so we don't need to do it before passing qty_to_take as parameter). opw-5136050 Forward-Port-Of: odoo/enterprise#97005