Daily updates from Odoo
Tuesday, February 24, 2026
9 changes · master
Resolved issues and error corrections
This update ensures that timesheet entries with negative hours exceeding six digits are now properly validated, preventing incorrect data entry. Previously, users could add entries with excessively large negative values without any error message. This fix improves data accuracy and reliability within the timesheet tracking system.
Original PR description
Currently, a user can add a timesheet entry with a negative Hours Spent value `exceeding six digits`. **Steps to reproduce:** - Install the `timesheet_grid` module. - Open the `Timesheets` app and…
Currently, a user can add a timesheet entry with a negative Hours Spent value `exceeding six digits`. **Steps to reproduce:** - Install the `timesheet_grid` module. - Open the `Timesheets` app and click `Add a line`. - Set Hours Spent to a `negative` value with more than six digits (e.g., -1000000). **Observation:** The line is added without any warning, whereas entering a positive value with more than six digits correctly raises an `error`. **Root cause:** At [1], the constraint validates only positive values exceeding six digits. As a result, negative values with more than six digits are not checked and bypass the `UserError validation`. **Fix:** This commit updates the constraint to ensure the six-digit limit applies to both positive and negative values. [1]: https://github.com/odoo/enterprise/blob/660905872909405c0a07a8317b4eb0a42e5854ca/timesheet_grid/models/analytic.py#L46-L49 opw-5909417 Forward-Port-Of: odoo/enterprise#108182 Forward-Port-Of: odoo/enterprise#106781
This update optimizes the master production schedule (MPS) by fixing an issue where unnecessary data was being loaded during order processing. The change prevents the system from pulling in irrelevant product information, resulting in a significant speed improvement. The action replenish now completes successfully.
Original PR description
When traversing X2many fields (bom_ids, bom_line_ids) during prefetching in filtered, the _prefetch_ids data grew excessively. Prefetching bom lines pulled in IDs for lines belonging to all boms across all associated products, even though _skip_bom_line in this case only operates on the current product's context. Use prefetch() with no args to avoiding unnecessary record loading for unrelated boms. Benchmark: | |Before |After| |-----------------|-------|-----| |action_replenish |Timeout|577ms| Related ticket: opw-5928055 Forward-Port-Of: odoo/enterprise#107648
This update fixes an issue where OCR-extracted expense amounts weren't correctly converting to the company's standard currency (USD). The change ensures that the 'Total' amount accurately reflects the receipt's original currency value, using the correct exchange rate. This improves the accuracy of expense reporting.
Original PR description
Steps to reproduce: 1. Initialize an expense with a foreign currency (e.g., EUR). 2. Trigger OCR extraction on a receipt with a specific total. 3. Observe that both 'Total In Currency' and 'Total' (USD) are set to the same value. 4. The exchange rate is forced to 1.0, ignoring the system's exchange rate. Cause: The _fill_document_with_results method assigned the OCR total to both 'total_amount_currency' and 'total_amount' as a placeholder. This triggered the field's inverse logic during the write() call, causing Odoo to treat the input as a manual exchange rate override of 1:1. Solution: Remove the 1:1 placeholder assignment. The method now explicitly calculates 'total_amount' using the _convert() helper once the currency is identified, ensuring the company currency total reflects the actual system exchange rate. opw-5437611 Forward-Port-Of: odoo/enterprise#108089 Forward-Port-Of: odoo/enterprise#107534
This update resolves an issue where users within the 'Planning / User' group couldn't take open shifts. The fix ensures that the 'I Take It' button is consistently displayed for this group, allowing them to seamlessly accept shifts as intended. This improves the planning process for staff.
Original PR description
## Issue In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift. ## Steps to reproduce…
## Issue
In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift.
## Steps to reproduce
1. Install the *Planning* (`planning`) app
2. In the Planning app, as an admin, create and publish an open shift
3. Log in as a *User*, open the *Planning* app, and click on the open shift
4. **The _"I Take It"_ button is not displayed**
When logging in as a user who is **not** part of the *Planning / User* group, the *I Take It* button is displayed.
## Cause
The condition for the *I Take It* button to be displayed is the following:
https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L282-L283
The condition that makes the button invisible is `not context.get('my_planning_action')`. When the user is part of *Planning / User*, the schedule they see when opening the *Planning* app is the *"Schedule by Resource"*, which has the following context:
https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L716
When a user who **is not** part of the *Plannig / User* group opens the *Planning* app, they see their own schedule, where the context is different than in the first case:
https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L636
Because the `my_planning_action` property is in the context (and all the other conditions are respected), the button is displayed.
opw-5451282
Forward-Port-Of: odoo/enterprise#104919This update ensures the MO filter remains active in the shopfloor search bar after a user clicks on a manufacturing order's header. Previously, clicking the header would remove the filter, causing confusion. This fix maintains the correct filter context, improving usability and workflow efficiency.
Original PR description
### Steps to reproduce: - Download MRP app. - Create a product and its corresponding BOM (including at least a single operation) - Create and confirm a manufacturing order for 1 unit of that product…
### Steps to reproduce: - Download MRP app. - Create a product and its corresponding BOM (including at least a single operation) - Create and confirm a manufacturing order for 1 unit of that product - Click on the Shop Floor smart button > Click on the header of the MO - The MO filter applied on the shopfloor search bar is removed ### Issue: The MO search filter is removed after you click the header of the workorder order. This bug was introduced by another commit https://github.com/odoo/enterprise/pull/94584/changes/c83ab24a8d037a339db8067c7e9794cba5c16eab to remove the filter when a workorder's barcode is scanned. Hence, https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L289-L292 the change resulted in the filter being removed every time the header is clicked. In the case where a user clicks to start the workorder, we need to keep the filter. ### Fix: Based on https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L6-L8 `onClickHeader()` is called every time a shopfloor record is clicked, which (based on the reference in the previous section) removes the filter, then calls `startWorking()`. By removing `this.env.searchModel.removeMOFilter()` from this method, it's ensured that clicks preserve the user's current search context. For https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display.js#L248-L250 since the original workflow of removing the filter in case of a barcode scan should be kept, moving `removeMOFilter()` call here with the appropriate reference of `workorder.component.env.searchModel`matches the expected behaviour. opw-5877418 Forward-Port-Of: odoo/enterprise#107121
A technical problem with the Hong Kong payroll calendar was causing errors that prevented new employees from being created. This update corrects the calendar's setup to use the correct work entry types, resolving the issue and restoring functionality.
Original PR description
The resource calendar for Hong Kong doesn't work well at the moment. When the data is loaded, it picks the company from the env (usually a US one during db initialization) and the country from it. Using that country, it deduces the work entry type for the attendance_ids. At the moment, the result is that HK calendar ends up with US work entries, causing access errors in certain flow. (e.g. With hr_contract_salary installed you can no longer create employees). The solution is to explicitly set the company_ids to False as done in other countries to have the generic work entry set and bypass the issue. Forward-Port-Of: odoo/enterprise#108250
This update addresses several issues causing crashes related to tracking functionality within Odoo Enterprise. The team has focused on using accurate date/time data instead of strings, streamlining tests, and resolving a bug related to loop usage in multi-mode environments. These changes enhance the stability and reliability of the helpdesk, payroll, and expense tracking modules.
Original PR description
Forward-Port-Of: odoo/enterprise#108286
This update fixes a bug in the payrun process where clicking 'Continue' on validated steps would incorrectly block access to the next step. The fix corrects a misconfigured context key and ensures the increment logic only executes when the active step matches the stored step, improving the user experience.
Original PR description
Problem --------- If you click on Continue on a future step, it will validate all the previous step. If you click on Continue on a validated step it will not give you back the next step if it's already incremented Solution --------- The context key was wrong. The behavior of the increment was wrong too: the increment should be executed only if the current active step is the same as the stored step. task-5960023
This update enhances the skills evolution report to provide a more accurate and historical view of employee skill development. By tracking skill changes through a new data model, the report now aggregates average progress across the organization, offering a better understanding of overall skill trends and development needs.
Original PR description
. Fix & Refactor the Skills Evolution Report to provide an accurate, historical view of skill progression across the emplyees. Key changes include: . Historical Skill Tracking: The report now calculates skill evolution by querying hr_employee_skill for each employee, instead of relying on the previous skill level field (previous_skill_level_id). This ensures historical changes are correctly captured, even for skills added or updated over time. . Average Progress Across Employees: The report now aggregates the average progress of each skill across all active employees, providing a true organizational-level skill evolution metric. task-5106696