Tuesday, March 3, 2026
12 changes · saas-18.4
Resolved issues and error corrections
This fix prevents phone number fields from becoming too narrow on mobile contact forms. Users can now edit phone numbers more reliably because action buttons take less space and the input uses the available width.
Original PR description
Steps to reproduce: 1. Install `contacts` 2. Create an individual contact with a phone number 3. Try to edit the phone number on the mobile Issue: - Unable to edit in mobile view Cause: - On mobile…
Steps to reproduce:
1. Install `contacts`
2. Create an individual contact with a phone number
3. Try to edit the phone number on the mobile
Issue:
- Unable to edit in mobile view
Cause:
- On mobile devices, the utility buttons (Call, SMS, WhatsApp) inside the phone widget consume significant horizontal space. Due to the flex layout, this forces the actual phone input field to shrink too much, making it hard/impossible to view or edit the number.
Solution:
- Hide the text labels of the utility buttons to save space, showing only the icons
- make input's width 100% on mobile screens in partner form
<table>
<thead>
<tr>
<th>Before</th>
<th>After</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">
<img
src="https://github.com/user-attachments/assets/a620d417-119e-4e28-a62b-f63031e72598"
alt="Before"
width="500"
/>
</td>
<td align="center">
<img width="500" height="354" alt="image" src="https://github.com/user-attachments/assets/6adc4c77-767d-491d-a468-8463c0f77666" />
</td>
</tr>
</tbody>
</table>
opw-5489021
Forward-Port-Of: odoo/odoo#246295Sales orders opened in Point of Sale now keep the correct lot information when the same lot is split across multiple stock locations. This prevents checkout from assigning more items to one location than it actually has, improving inventory accuracy for tracked products.
Original PR description
When opening an SO in POS that has a product tracked by lot that is split into several location, the lot number will only appear in one of the line and not the others Steps to reproduce:…
When opening an SO in POS that has a product tracked by lot that is split into several location, the lot number will only appear in one of the line and not the others Steps to reproduce: ------------------- 1. Create a Product A tracked by lot, create lot 111 and add 1 unit to location A and another one to location B 1. Create a sales order 2. Add two units of the product to the sale order 3. Confirm the sales order 4. Open the transfer, make the transfer retrieve the product from several location with the same lot. 5. Save the transfer 6. Open the sales order in POS 7. Load the SN/lots -> Two line of qty 1 appear for the product A but only the first one has the lot number Additional Issue: 8. Change the number of the product for the first line to 2 and erase the second line 9. Confirm and Pay 10. Close POS 11. Open move lines for this product (Inventory>product>In/out) -> It moves 2 product from one location (when there is only product) Observation: ------------- When loading the SO in POS, we will retrieve the SO: https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/pos_sale/static/src/app/order_management_screen/sale_order_management_screen/sale_order_management_screen.js#L104 While retrieving the SO, we will also retrieve the SOL, with additional information: https://github.com/odoo/odoo/blob/d9b2e5ee730a4e79586bfd3f09adfb794d2dc1f3/addons/pos_sale/models/sale_order.py#L79 -> Issue is that when several moves_line have the sale lot_id.name, their quantity will be overwritten. Addition Issue : When closing pos, all the move will be processed, when processing those moves, the origin only check if the quantity is more than 0 and not if there is enought units. https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/point_of_sale/models/stock_picking.py#L293-L297 opw-5347992 Forward-Port-Of: odoo/odoo#251270 Forward-Port-Of: odoo/odoo#243347
This fixes an issue where Danish Nemhandel document sending could show or keep the wrong status when processed in the background. Businesses using Danish electronic invoicing should see more reliable tracking of sent documents and fewer confusing follow-up actions.
Original PR description
State is not being correctly managed in case of background processing. task-5963885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251219
This fixes a multi-company issue where a customer's Brazilian fiscal settings could be read from the wrong company, causing errors when adding products to Field Service tasks. The system now uses the current company's fiscal position, improving reliability for businesses operating across multiple companies.
Original PR description
Issue ===== The fiscal position defined on a partner was not properly isolated per company, leading to cross-company inconsistencies and errors. Steps to Reproduce ================== 1. Install…
Issue ===== The fiscal position defined on a partner was not properly isolated per company, leading to cross-company inconsistencies and errors. Steps to Reproduce ================== 1. Install `industry_fsm_sale` and `l10n_br`. 2. In the US company: - Create a Brazilian customer. - Set a fiscal position on the customer. 3. Switch to the Brazilian company: - Open the same customer. - Set a fiscal position on the customer. 4. Still in the Brazilian company: - Create a task for that customer in the Field Service app. - Add a product to the task. Result ====== An error is raised because the fiscal position from the US company is used, which is not valid for the Brazilian company. Root Cause ========== When reading the fiscal position from the partner, the value is fetched in the environment of the company in which the partner record was originally created (US company). If no company is explicitly specified, the fiscal position is read in that original environment, even when the user is operating under the Brazilian company. Solution ======== Explicitly enforce the current company context when reading the fiscal position from the partner to ensure the correct company-specific value is used. opw-5270522 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250115 Forward-Port-Of: odoo/odoo#249482
Updating a bill of materials for a draft manufacturing order no longer causes a missing record error. The fix keeps the update process from trying to delete work orders or stock moves that were already removed, making BoM updates more reliable for manufacturing users.
Original PR description
Steps to reproduce: - Create a storable product P1 with the following BoM: - Component: C1 - Operation: OP1 - Create a draft MO for P1 - Update the BoM by adding a new component - Go back to the MO…
Steps to reproduce:
- Create a storable product P1 with the following BoM:
- Component: C1
- Operation: OP1
- Create a draft MO for P1
- Update the BoM by adding a new component
- Go back to the MO and click "Update from BoM"
Problem:
Missing Record
Record does not exist or has been deleted.
(Record: mrp.workorder(8,), User: 2)
Clicking on `update bom` will launch a call of the `action_update_bom`
which will itself call the `_link_bom` to update the record:
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80
https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418
The function will sets `bom_id` to False, which triggers
`_compute_workorder_ids` and `_compute_move_finished_ids`
(depends on bom_id). As the MO is in draft, related moves and
workorders are deleted.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L849
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L659
After that, it will try to delete the work orders again, and
since the operation no longer exists, an error will be triggered.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L2586-L2587
opw-5947687
Forward-Port-Of: odoo/odoo#251020
Forward-Port-Of: odoo/odoo#249336This fix prevents website popups from accidentally disappearing when users edit or preview backdrop color changes and then undo or redo actions. It keeps popup visibility separate from styling changes, making the website builder more reliable for editors.
Original PR description
Steps to reproduce in 18.4: - Add a popup on the page - Click on the popup - Change the backdrop color - Hide the popup by clicking on its entry in "Invisible Elements" - Undo - Redo - Bug: The popup disappears Steps to reproduce in 19.0: - Add a popup on the page - Click on the popup - Hover a color in the colorpicker of the backdrop option of the popup - Stop hovering the color - Bug: The popup disappears
This update ensures the IEPS (tax) breakdown on Mexican invoices (CFDI) accurately reflects requirements from the SAT tax catalog. Specifically, the system now correctly displays IEPS only for global invoices or when a specific tax object (07) is used, aligning with current regulations.
Original PR description
This commit targets to modify the behaviour of IEPS breakdown on CFDI to follow on what is specified on SAT cfdi Tax Object Catalog. Now the IEPS will be displayed only considering if the CFDI is a global invoice, the value of the tax object and whether the check is set. The general idea is: - Is a global invoice? -> show IEPS - Is tax object 07? -> show IEPS - Has ieps breakdown but is not tax object 08? -> show IEPS - Anything else, don't. task-5953499 target: saas-18.4 -> master
This update resolves a problem where the automated processing of Brazilian e-invoices (BR-EDI) was failing due to a flawed cron job setup. The fix ensures invoices are processed in smaller batches, with individual commits to prevent data loss and wasted credits. This improves the reliability of the BR-EDI service.
Original PR description
The cron searched with limit=batch_size and only retriggered when >batch_size records were found which never happens. It also ran all invoices in a single transaction so one failure rolled back all progress while IAP credits were already consumed. Search batch_size + 1 so remaining invoices are detected, and commit after each invoice to preserve progress. opw-5954211 Forward-Port-Of: odoo/enterprise#108468 Forward-Port-Of: odoo/enterprise#108191
This update resolves a crash issue that occurred when viewing pay runs on mobile devices. The fix ensures the system correctly identifies and interacts with the Kanban view, preventing unexpected errors and improving stability for users. This change maintains the existing mobile layout while addressing a critical functionality problem.
Original PR description
**Steps to Reproduce:** 1. Open Payroll->Payslips->Pay Runs 2. Click on a Pay Run in Mobile View (Width < 600px). 3. Return to the previous view using the breadcrumb. 4. The system crashes with Traceback: TypeError: Cannot set properties of null (setting 'scrollLeft') **Bug Cause:** The custom 'hr_payroll.PayrunKanbanRenderer' template overrode the 'class' attribute of the root div. By setting it only to 'o_payrun_kanban', the standard 'o_renderer' class was removed. The Kanban controller's scroll restoration logic (introduced in recent lazy-loading updates) relies on the '.o_renderer' selector to find the scrollable container. When missing, querySelector returns null, leading to a traceback. **Solution:** Updated the XML template to explicitly include 'o_renderer' in the class list. This restores the functional hook required by the JavaScript controller for scroll restoration while maintaining the custom 'o_payrun_kanban' layout. Task: 5971861
This update resolves an issue preventing the export of Eco-Voucher reports from the Belgian Payroll App. The change addresses a technical update related to versioning, specifically removing a deprecated 'state' field and aligning data with the new version module. This ensures accurate Eco-Voucher exports for Belgian companies.
Original PR description
Since the switch from contracts to versions, exporting Eco-Vouchers to excel has not been functional, this commit fixes this. **Steps to reproduce:** - Open Payroll App as a Belgian company - Under Reporting Menu, select Eco-Vouchers - Try exporting with XLSX **Issue:** Since introduction of versions, version module does not contain state field anymore which was present in contracts **Fix:** Removed the state field and replaced it with the corresponding field in version. task:5163668
This update resolves an issue where rapidly clicking the 'Back' button during barcode internal transfer creation resulted in duplicated quantities being added to the transfer. The fix prevents multiple 'save' calls, ensuring accurate quantity tracking.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By…
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By Quantity** and set some *barcode* * Update the on-hand quantity for the product and assign it to one packages. * Open *Barcode > Operations > Internal Transfer* and create a new transfer. * Click the *gear icon* in the top-right corner to open the barcode scanning flow. * manually enter the created product barcode and apply it. * Click the **Back** button multiple times in quick succession. * Go to the backend and open the created internal transfer. **Observed behavior:** * The internal transfer is created with *double quantities* compared to what was added in the barcode interface. **Cause:** * When clicking the *Back* button, the following flow is triggered: `exit()` → `beforeQuit()` → `save()`. https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483 * If the button is clicked multiple times rapidly, `exit()` is called again before the previous `save()` RPC completes. * This results in multiple `save()` calls being executed, causing duplicated quantities on the picking. reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74 **Fix:** * Prevent rapidly clicking the Back button multiple times does not multiply quantities. --- opw-5375899 Forward-Port-Of: odoo/enterprise#109013 Forward-Port-Of: odoo/enterprise#103130
This update corrects an issue where payments for invoices paid within 30 days (PUE) were incorrectly sent to the Mexican tax authority (CFDI). By disabling a specific function, we now ensure that only payments meeting the required 30-day term are processed for CFDI submission, improving compliance and accuracy.
Original PR description
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm…
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm - Duplicate (Invoice B) - Confirm - Duplicate again (Invoice C) - Set Payment Terms to "30 days" - Confirm - Go to Invoice A - Pay it. It should appear as "Paid" - Send it to CFDI - Go to Accounting > Customer > Invoices - Select Invoice B and C - Pay and select the "Group Payments". They should appear as paid. - In every invoice, click the "Update Payment" button Current behavior: - In Invoice A -> Sheet CFDI: A button "Force CFDI" allow sending the payment to CFDI - In Invoice B/C -> sheet CFDI: Click on the "Download" part of the Payment line, the XML that was sent to CFDI include both invoice B and C Expected behavior: - It shouldn't be possible to send payment for invoice A to CFDI. - Payment for invoice B shouldn't be sent to CFDI Cause: Payment for invoice paid in less than 30 days, referred as PUE, shouldn't be sent to CFDI. Solution: Disable the force sending to CFDI About tests: l10n_mx_edi_cfdi_invoice_try_update_payments already send payment to CFDI for PPD invoices. Calling action_force_payment_cfdi was pointless and causing a mess. opw-5381600 Forward-Port-Of: odoo/enterprise#109105 Forward-Port-Of: odoo/enterprise#104628