Wednesday, March 11, 2026
8 changes · 18.0
Resolved issues and error corrections
This update clarifies server logs related to data imports by adding more specific information about which models the data was imported into. Previously, it was difficult to quickly determine if an import was a dry run or a real import, and the logs didn't always state the target model. This change makes it easier for support teams to troubleshoot import issues and improve overall data management.
Original PR description
When investigating support tickets (and the server logs), it is not always clear if: 1) The `info`` log from base_import refers to a dry run or a "real" import 2) The "done" log does not explicitly specify which model the data was imported to While an experienced user can still extrapolate what happened by the immediate context of the preceding/following log lines, it makes it unnecessary difficult to see at first glance where the data was imported to. This PR aims at rectifying it to improve the quality of life of people investigating the server logs. OPW-5999195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252783 Forward-Port-Of: odoo/odoo#252734
This update fixes an issue where the MPS wasn't accurately reflecting demand for dependent components. Previously, the system defaulted to the oldest BoM, regardless of the user's selection. Now, the system uses the BoM specified in the product schedule, ensuring correct demand calculations and inventory updates.
Original PR description
## Issue: When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which…
## Issue:
When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which BoM he wants to use. `_bom_find` ignores the user configuration in MPS, and simply select the first (oldest) BoM in the list. This means that the components in the MPS would not be correctly updated.
---
## How to reproduce:
https://github.com/user-attachments/assets/c7e6f4d4-332a-4e2b-a40a-1b831daeb6c8
- Create Products FNS & CMP
- Create BoM for FNS without bom line (V1)
- Create BoM for FNS with CMP in bom lines (V2)
- Add FNS to MPS using bom V2
- Set Forecast Qty of FNS to 10
- => Indirect Demand Qty for CMP is not shown (because it's 0)
---
## Test Result without fix:
```
2026-03-05 15:00:24,601 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: Starting TestMpsMps.test_indirect_multiple_boms ...
2026-03-05 15:00:24,742 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: ======================================================================
2026-03-05 15:00:24,742 52396 ERROR oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: FAIL: TestMpsMps.test_indirect_multiple_boms
Traceback (most recent call last):
File "/home/odoo/Odoo/src/18.0/enterprise/mrp_mps/tests/test_mrp_mps.py", line 1556, in test_indirect_multiple_boms
self.assertEqual(forecast_cmp['forecast_ids'][0]['indirect_demand_qty'], 10)
AssertionError: 0.0 != 10
```
---
OPW-5979738This update resolves an issue where expense reports created from incoming emails weren't being generated due to a company mismatch. The fix ensures the system always uses the employee's company when creating an expense, regardless of user assignments, preventing the 'Incompatible companies' error.
Original PR description
**Steps to reproduce:** - Install Expenses - Activate "Incoming Emails" in the settings - Configure the expense Alias - Configure an "Incoming Mail Server" - Create a Branch for a company - Create a…
**Steps to reproduce:** - Install Expenses - Activate "Incoming Emails" in the settings - Configure the expense Alias - Configure an "Incoming Mail Server" - Create a Branch for a company - Create a User: * Email Address: [an existing email address] * Allowed Companies: [the parent company + the branch company] * Default Company: [the branch company] * User Types: Internal User - Create an employee for the user in the parent company - From the email address, send a PDF to the expense alias **Issue:** The expense is not created in the database due to a UserError: "Incompatible companies on records". **Cause:** When the email is received and treated, the system tries to create an expense. From the email address, it retrieves an employee that is linked to the expense. For the company of the expense, if a user is linked to the employee, it takes the default company of the user. Otherwise, it takes the company of the employee. In this case, the company set on the expense is the default company of the user (i.e. the branch company) and the employee set on the expense belongs to the parent company ; which triggers the UserError during the company check. **Solution:** Always use the company of the employee, even if there is a user linked to the employee. opw-5346809 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A bug preventing users from copying their two-factor authentication secret via the portal has been resolved. The update corrects a technical issue where the 'copy' button's functionality was lost after a recent code change. This ensures users can reliably access and copy their security codes.
Original PR description
__Problem__ Since odoo/odoo@e3da5f1 the onclick listener set on `copyButton` is lost because we give the HTML of the body as argument at the dialog creation. __Steps to reproduce__ 1. Go to `/my/security` 2. Click on "Enable two-factor authentication" 3. Confirm password 4. Click on "Cannot scan it?" 5. The "Copy" button doesn't work __Fix__ - Inherit from `InputConfirmationDialog` to add a listener to the button. - At the same time, remove the remaining jQuery dependency in this part of the code Forward-Port-Of: odoo/odoo#251429
This update resolves a recurring issue where the Italian POS system generated errors when offline, specifically when printing receipts. The fix adds a safety mechanism to gracefully handle network disruptions during receipt printing, preventing crashes and improving the user experience. This ensures reliable operation even without an internet connection.
Original PR description
When loosing internet connexion a lot of tracebacks appear is the pos if we use the italian fiscal printer. Steps to reproduce: ------------------- * Setup italian fiscal printer for a shop * Open shop * Turn wi-fi off * Add items to cart * Go to payment screen > Traceback * Add a payment and validate > Traceback Why the fix: ------------ Don't try to reach the printer if we're offline regarding the price to pay. We add a try catch block around the call for printing the receipt. If the try block fails when the network is offline we assume it's just because of the offline mode. If it failed while online we raise the error. opw-5432090
This update ensures that self-order prices are consistently calculated by the backend before payment processing. Currently, changes made to product prices via the client-side interface could lead to incorrect payment amounts without any notification. This fix guarantees accurate pricing for self-order transactions, improving financial reporting and trust.
Original PR description
The price computation is done on the backend only for combo products. This means that someone can order stuff on the self order, change the price of the products through JS on the client, and then when they go to pay the backend would generate a payment for the modified price and register everything as normal without any indication to the owner that the price was modified. This change will force the backend to recompute the price before creating the payment based on the standard prices defined on the backend. This only applies on self orders, so cashiers should still be able to modify prices on the frontend of the normal POS Task-[5864068](https://www.odoo.com/odoo/project/1737/tasks/5864068) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue in the payroll batch payslip wizard where the displayed contract type was incorrectly defaulting to the first contract, regardless of its status. Now, the wizard accurately reflects the running contract type for employees with multiple active contracts, ensuring accurate payroll calculations.
Original PR description
Currently, in the batch payslip wizard, the 'Salary Structure Type' is determined by the first contract found for the employee. ### **Steps to Reproduce:** 1) Install Payroll. 2) Create an employee…
Currently, in the batch payslip wizard, the 'Salary Structure Type' is determined by the first contract found for the employee. ### **Steps to Reproduce:** 1) Install Payroll. 2) Create an employee with two contracts: - Contract A: Expired, From DEC 1st 2025 to 31st DEC 2025, salary structure as 'Employee' - Contract B: Running, Starts from Jan 1st 2026, salary structure as 'worker'. 3) Navigate to Payroll>payslips>Batches and click 'Generate Payslips'. ### **Observed Behaviour:** The column displays the Structure Type of Contract A(Expired): `Employee`. ### **Expected Behaviour:** The column should display Contract B(Running) in the Structure Type column: `Worker`. ### **Root Cause:** The `structure_type_id` field was defined as a related field on `contract_ids`. Due to this, it always fetches the first record based on the default sort order. ### **Fix:** Replace the relation of structure_type_id with `contract_id`. To ensure running contracts (state='open') are recieved, regardless of their start dates. **opw-5311933**
This update fixes several issues related to the mobile view of online orders, including missing buttons and order cancellation problems. Users can now consistently access order details and seamlessly cancel Swiggy online orders, improving the overall mobile ordering experience. This enhancement ensures a smoother and more reliable process for mobile users.
Original PR description
*: pos_restaurant_urban_piper Before this commit: ========== - "Load Order" and "Review" buttons were not visible for online orders. - The "Review" button was missing for paid online orders, preventing users from reviewing their orders. - The "Info" button was not visible for paid orders, restricting users from checking order details after payment. - A traceback occurred when cancelling a Swiggy online order. After this commit: ========== - Improved mobile view for online orders, ensuring a more consistent user experience. - Fixed the issue preventing Swiggy online order cancellations, allowing seamless cancellations. Related PR: - https://github.com/odoo/odoo/pull/213769 task-4657597