Daily updates from Odoo
Tuesday, June 16, 2026
12 changes · 19.0
Resolved issues and error corrections
This update optimizes the MRP work order process by preventing unnecessary BoM explosions for non-material quality points like instructions and pass/fail checks. Previously, this process was slow, but now it's significantly faster, reducing processing time by orders of magnitude. This improves overall system responsiveness and efficiency.
Original PR description
`_compute_component_ids` unconditionally called `bom.explode()` for every product variant on the BoM, even for quality point types (`instructions`, `pass_fail`, etc.) that never use the `component_id` picker. The field is only meaningful for `register_consumed_materials` and `register_byproducts`. Restrict the expensive path to those two types with an `elif` so all other types return `component_ids = False` immediately. | # Input data | Before PR | After PR | |:---:|:---:|:---:| | 10 variants, 10 components, 2 phantom BoMs, 3 ops | 841 ms | 0.1 ms | | 30 variants, 20 components, 5 phantom BoMs, 3 ops | 1,343 ms | 0.1 ms | | 80 variants, 40 components, 12 phantom BoMs, 5 ops | 8,674 ms | 0.1 ms | OPW-6210368
This update corrects a potential issue in the Swiss payroll module where users could incorrectly request refunds for payslips. Swiss regulations limit one payslip per month, so the system now directs users to cancel and re-create the payslip for any necessary corrections, ensuring compliance with Swiss tax laws.
Original PR description
Prevent refunds for CH payslips since only one payslip per month is allowed for Swiss payroll. Users should cancel the payslip and create a new one to apply corrections. task-5951981 Forward-Port-Of: odoo/enterprise#107943
This update corrects a bug that occurred when a subformula was removed from a report without resetting its value. This prevented errors during record processing, ensuring reports could be generated correctly. The change resets subformula values to 'False' to avoid future issues.
Original PR description
The subformula was [removed](https://github.com/odoo/enterprise/pull/117601) without resetting its value to False, leaving existing values in the database. This causes errors when processing records that still contain a subformula value. ```.py Invalid subformula in expression "balance" of line "Treasury shares": -sum ``` To prevent these errors, existing subformula values are reset to False opw-6297901
This update corrects a bug where selection fields in Odoo's web studio were incorrectly flagged as required, even when not explicitly marked so. The change ensures that required fields are only applied when explicitly set to 'true', preventing unexpected behavior and improving the usability of the studio for users creating and editing forms.
Original PR description
Before: any studio property using a SelectMenu (selection) component, without a `required: false` in the childProps, was implicitly required because the check used `required !== false`, which evaluates `undefined` as truthy. After: `required` is only applied when explicitly set to `true`. task-5226503
This update resolves an error that prevented Manufacturing Administrators from canceling Manufacturing Orders (MOs) due to access restrictions. The fix adds sudo privileges to allow cancellation, streamlining the process for administrators without requiring full accounting permissions. This improves efficiency and reduces potential disruptions.
Original PR description
Currently, when a user without accounting permissions attempts to cancel a Manufacturing Order (MO), an Access Error is raised. ## Steps to produce: - Install Manufacturing and Accounting with demo…
Currently, when a user without accounting permissions attempts to cancel a Manufacturing Order (MO), an Access Error is raised. ## Steps to produce: - Install Manufacturing and Accounting with demo data. - Users > Marc Demo > Remove Accounting Permissions and give Admin permissions for Manufacturing - Login as Marc Demo - Create an MO for` [D_0045_G] Stool (Green) `and try to cancel it. ## Observed Behavior: Failed to read field mrp.workorder.employee_analytic_account_line_ids ## Root cause: After PR [1], version 19.0 introduced access checks when reading many2many fields. As a result, if a user lacks read access to a model field, an access error is raised. During cancellation, `action_cancel` [2] is called, and the error occurs when unlinking, since the user does not have read access to the account.analytic.line records the system throws an access error. **Why does this error not occur in 19.3+?** Commit [3] added `sudo` to allow cancellation of workorder [2]: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder_hr_account/models/mrp_workorder.py#L24-L26 ## Solution: Manufacturing Administrators often need to cancel MOs and WOs, but granting them accounting rights solely for this purpose is not always necessary. A practical solution is to allow MO cancellation through sudo privileges, which can be achieved by backporting [3]. [1]: https://github.com/odoo/odoo/pull/217277 [3]: https://github.com/odoo/enterprise/commit/31cf5f014c48b97158042e64ad0b8e9827a6c0d5 Related Community PR: https://github.com/odoo/odoo/pull/264925 opw-6204049
This update resolves an error preventing users from accessing the 'Due' report within the account reports module. The issue stemmed from a missing configuration setting ('cellIndex') in a key component. This fix ensures the 'Due' button now functions correctly, allowing users to generate the report as intended.
Original PR description
**Steps to reproduce:** - Install the `account_reports` module and enable developer mode. - Navigate to Invoicing > Customers > Customers. - Open the `Acme Corporation` record. - Click the `Due`…
**Steps to reproduce:** - Install the `account_reports` module and enable developer mode. - Navigate to Invoicing > Customers > Customers. - Open the `Acme Corporation` record. - Click the `Due` smart button. **Error:** `OwlError: Invalid props for component 'PartnerLedgerFollowupLineCell': 'cellIndex' is missing (should be a number)` **Root Cause:** In commit [1], `cellIndex` was added as a required props to `AccountReportLineCell`. However, `PartnerLedgerFollowupLineCell` at [2] was not updated to pass this props, causing an error. **Fix:** This commit prevents the error and ensures that users can open the `Follow-up` Report. [1]: https://github.com/odoo/enterprise/commit/ae3e71164bea8883417793bad0bfa5ef72db758f [2]: https://github.com/odoo/enterprise/blob/3c4e2259ec8fb67d799806d94ffe40ab6a40f25e/account_reports/static/src/components/partner_ledger_followup/line/line.xml#L7 opw-6296374 opw-6299717 opw-6300704 opw-6301870 opw-6245448 opw-6302816 opw-6298215 opw-6303774 opw-6301046 opw-6304518 opw-6305071 opw-6306193 opw-6306219 opw-6308514 opw-6308957 opw-6312342 opw-6312746 opw-6313506 opw-6314075 opw-6315101
This update fixes a critical issue where leave schedules were incorrectly preventing resource allocation, now only applying to resources with matching calendars. Additionally, tests have been reorganized and improved to ensure accurate functionality, particularly related to shift rental planning.
Original PR description
## [FIX] sale_renting_planning: check global leaves working schedule Before this commit: any `resource.calendar.leaves` with no `resource_id` created would prevent all resources from being allocated…
## [FIX] sale_renting_planning: check global leaves working schedule
Before this commit: any `resource.calendar.leaves` with no `resource_id` created would prevent all resources from being allocated during the leave date.
After this commit: any `resource.calendar.leaves` with `no resource_id` would be applied only to resources with the same `calendar_id` as the leave.
if the leave has no `calendar_id` then the leave applies to all `resource.calendars`
if a resource has no `calendar_id` then leaves with no `calendar_id` apply to it as well
## [IMP] {website_}sale_renting_planning: move tests from industry and fix existing ones
This commit moves the tests from [odoo/industry#1980](vscode-file://vscode-app/snap/code/237/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html) to their respective standard modules.
It also fixes the logic behind some tests as they weren't testing a `planning.role` with `sync_shift_rental` enabled.
task-6179505This update corrects a rounding issue in overtime calculations, ensuring accurate payment for fractional hours. Previously, overtime durations were rounded to 3 decimal places, leading to potential inaccuracies in payroll. The fix now maintains 4 decimal place precision for overtime durations, guaranteeing correct monetary calculations.
Original PR description
Overtime duration computed as fractional hours was rounded to 3 decimal places before being stored on the overtime line. Since 1 decimal hour = 3600 seconds, this gives only 3.6 seconds of precision and the rounding can go in the wrong direction due to floating-point representation. The fix consists in replacing the duration rounding to 4 decimals when building overtime work entries so stored durations keep sub-second precision needed for money computation. task-6212231
This update resolves an issue where Intrastat CSV exports were failing due to incorrect formatting of numerical data. The fix ensures that data is properly converted to a standard numeric format before calculations, preventing errors and improving the reliability of export reports. This ensures accurate reporting for Dutch Intrastat data.
Original PR description
During Intrastat CSV export, fields `supplementary_units` formatted using [formatLang](https://github.com/odoo/enterprise/pull/81711/changes), which converts numeric values into strings (e.g.,…
During Intrastat CSV export, fields `supplementary_units` formatted using [formatLang](https://github.com/odoo/enterprise/pull/81711/changes), which converts numeric values into strings (e.g., '84,0'). These string values are later reused in computations, leading to errors like:
```.py
File "/home/odoo/src/enterprise/19.0/l10n_nl_intrastat/models/account_intrastat_report.py", line 163, in l10n_nl_export_to_csv
supp_unit = str(round(res['supplementary_units'])).zfill(10) if res['supplementary_units'] else '0000000000'
TypeError: type str doesn't define __round__ method
```
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/l10n_nl_intrastat/models/account_intrastat_report.py#L164 This occurs because the export logic expects numeric values, but receives localized strings or None.
Cause:
`formatLang` is applied at the report data level, converting floats into locale-formatted strings. These values are then used directly in arithmetic operations without normalization.
Fix:
Normalize values before computation by:
- Converting input to string
- Replacing locale-specific decimal separators (',' -> '.')
- Casting to float
- Falling back to 0 when value is None or empty
opw-6182286This update adjusts how the product list appears on tablets. Previously, it was always displayed in a smaller format. Now, it will display at its full size on tablets with screens between 768px and 991px, providing a better user experience on these devices. This ensures a more consistent and user-friendly product browsing experience.
Original PR description
Previously, the product list was rendered in "small display" mode for all screen sizes below the medium breakpoint (< 992px). However, some small tablets are able to fully display the product list at the medium breakpoint (≥ 768px and ≤ 991px). After this fix, "small display" mode is only applied when the screen width is below 768px. Task.6251934 Community: https://github.com/odoo/odoo/pull/266704
This update resolves two key issues related to attaching documents to employee records. Previously, attachments were created in the root 'Employees' folder, which was inconvenient. Additionally, creating sick leave attachments didn't always generate a document. This fix ensures attachments are correctly created in the appropriate folder and that all attachment types are properly recorded.
Original PR description
Before this commit, when adding an attachment to a leave or a employee version the mixin was configured to create the document in the root folder of Employees which was not very convenient. In addition, when creating a Sick leave with an attachment, no document was ever created. This commit fix both those bugs. Task-6095811 Forward-Port-Of: odoo/enterprise#119417 Forward-Port-Of: odoo/enterprise#112993
This update resolves two issues related to USPS shipping rates. Firstly, it now displays the correct unit of measurement (inches) for USPS package dimensions, eliminating confusion. Secondly, it ensures that rates are calculated based on the specific USPS service selected, not just whether the shipment is domestic or international.
Original PR description
Issue ----- There are 2 issues with USPS rest: 1. USPS packagings do not have their size UOM displayed. This leads to confusion as users input in inches but the dimensions are treated as feet. 2.…
Issue ----- There are 2 issues with USPS rest: 1. USPS packagings do not have their size UOM displayed. This leads to confusion as users input in inches but the dimensions are treated as feet. 2. USPS returns the same rate regardless of the package type. Steps to reproduce ----- - Set USPS up - Open the Package Type form > go to its' Dimensions tab > Issue 1 - Set USPS up (domestic) - Select a `Domestic Rating Indicator` (eg LF - Flat Rate Box) - Create a SO with some product - Open the delivery widget and add a rate with USPS - Discard the changes - Go to the delivery method and change the rating (eg SP - Single Piece) - Go back to the SO - Open the delivery widget and add a rate with USPS > Issue 2, rate is the same as before Issue 1 ----- By default, there is no displayed UOM on the form because of https://github.com/odoo/odoo/blob/38c737c2a4cc29b48235a100cfa9d6152af73826/addons/stock_delivery/models/stock_package_type.py#L20-L33 We can change this behaviour for USPS specifically as done in Envia https://github.com/odoo/enterprise/blob/20cc61e69aa3f6a59de1e962b25ce11fa402bf22/delivery_envia/models/stock_package_type.py#L37-L46 Issue 2 ----- In `usps_rest_rate_shipment`, we request rates for every package of the delivery, which we receive as lists. We then iterate over the list to find the rate matching the `mail_class`. The problem is that this only filters over whether the delivery is domestic or international. We don't filter based on the actual service selected on the carrier (`usps_domestic_rating_indicator` for domestic and `usps_international_rating_indicator` for international). https://github.com/odoo/enterprise/blob/20cc61e69aa3f6a59de1e962b25ce11fa402bf22/delivery_usps_rest/models/delivery_usps.py#L224-L236 ----- Ticket: opw-6224918