Wednesday, March 11, 2026
19 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue where the HTML editor wasn't accurately reflecting changes made by users. Previously, multiple edits could occur before the field was correctly marked as dirty, preventing users from seeing updates. This fix ensures that the HTML editor accurately tracks changes and updates the FormStatusIndicator correctly.
Original PR description
Prior to this commit, it was possible to: - make change A inside a html_field - save/commitChanges - make change B inside the html_field, before the end of the save/commitChanges - the field ends up incorrectly marked as "not dirty" (user can't use the FormStatusIndicator) even though change B was not committed yet. Solution: Give an id to the dirtiness, and associate that id with an extracted value from the editor. When the record update is done, mark the field as not dirty ONLY IF the current dirty id is the same as the id previously associated with the extracted value, else the field stays dirty. task-5976348 Forward-Port-Of: odoo/odoo#252655
This update resolves an issue preventing barcode scanning of product packaging when a product doesn't have a barcode defined. The fix ensures that the system now searches for the product when a barcode is scanned on packaging, allowing for seamless barcode scanning functionality within the Point of Sale module. This improves the user experience and accuracy of sales transactions.
Original PR description
Step to reproduce - Create a product - Add two attributes: 1. One with Instantly creation mode 2. One with Never creation mode - Define packaging from the Sales tab - Add a barcode on the variant packaging ex: 111356,11357 - Scan the packaging barcode in POS Observation: - we get a traceback `TypeError: Cannot read properties of undefined (reading 'product_template_attribute_value_ids')` Cause: - when we do not have barcode on product, when opening `openConfigurator` - (as we have few varianst) product get undefined. https://github.com/odoo/odoo/blob/f229f23d7bf3d837ff5577c36145bf2ba410ea22/addons/point_of_sale/static/src/app/services/pos_store.js#L738 - Hence the traceback Fix: - For the case, when packaging has barcode but not the product, we search for product in that case too. opw-5886570 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248838
This update fixes an issue where refund payments in Point of Sale were incorrectly created as 'inbound' instead of 'outbound'. When processing refunds with the 'Identify Customer on the Card' payment method, this change ensures accurate payment record creation, improving financial reporting and reconciliation within the invoicing system. The fix was implemented to address a specific workflow and is considered a minor improvement.
Original PR description
Step to reproduce: - Install point_of_sale - Enable Identify Customer on the Card payment method - Create an order with a customer and refund it - Use Card as the payment method - Close the POS…
Step to reproduce: - Install point_of_sale - Enable Identify Customer on the Card payment method - Create an order with a customer and refund it - Use Card as the payment method - Close the POS session - Go to Invoicing → Customers → Payments Observation: - Two payment records are created - Both payments have payment_type = inbound - The refund payment should be outbound Cause: - When Identify Customer is enabled, `_create_split_account_payment` is used to create payment records - The method does not adjust payment_type for refund transactions Fix: - Add helpers to swap destination and outstanding accounts - Set `force_outstanding_account_id` instead of `outstanding_account_id`, as the former has priority - Ensure refund payments are created as `outbound` few related fix: https://github.com/odoo/odoo/commit/303a9061da85048f14a3ca7b1e13df0ab34da99e https://github.com/odoo/odoo/commit/718fac6832ecd343bf26d41fa5ae5b1ab74f4228 https://github.com/odoo/odoo/commit/684415b9ff2e151506da561016dbfa991bfa8dc8 opw-5437456 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247760
This update enhances the clarity of Odoo's server logs during data imports. Previously, it was difficult to quickly determine if an import was a dry run or a real import, or to see which model the data was imported into. This change makes it easier for support teams to investigate issues and improve the overall efficiency of data import troubleshooting.
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 resolves an issue where the system incorrectly interpreted date columns in import files. Specifically, it fixed a problem where date formats like '2500/1222' were mistakenly identified as '%Y.%m.%d'. This ensures that import files with various date formats are processed accurately, preventing import errors and data inconsistencies.
Original PR description
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)…
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)  First column: Client ref Second column: committment date Third column: Customer ## Current behavior before PR: When you upload the file to import, the extract_header_types calls _try_match_date_time that try to guess the date column. The first column makes the _try_match_date_time to guess that the format is %Y.%m.%d format . This is an error because that column does not contain a date . The reason is that check_patterns when convert the pattern to reg ex using `def to_re(pattern):` on base_import/base_import.py, does not escape the "." so it works as "every char" wildcard character on regex . ## Desired behavior after PR is merged: No error should appear and the correct date format from the right date column should be guessed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252488 Forward-Port-Of: odoo/odoo#196477
This update corrects a bug that caused incorrect currency conversions during batch payment reconciliation in foreign currency journals. Specifically, when reconciling bank statements, the system was using the wrong currency for calculations, leading to inaccurate balances. This fix ensures accurate currency conversions for a more reliable reconciliation process.
Original PR description
When reconciling a batch payment in a foreign currency journal where payments do not have outstanding accounts, the resulting bank statement lines could use the wrong currency for balance conversion. Steps to reproduce: - Create a journal in a foreign currency (e.g., CHF) - Create two invoices in company currency (e.g., EUR) - Pay both invoices using the foreign journal - Create a batch payment for these payments. - Reconcile a bank statement line against this batch payment. Issue: Reconciliation make use of the payments amount in the wrong currency. Analysis: During the reconciliation of a batch payment, the system creates new amls from the payment values. However, the currency of the computed amount should be the source payment currency, and not the invoice line currency. opw-5887218
This update resolves an issue in the Odoo Report Editor where certain field types were not correctly supported. The change prevents users from attempting to select fields with properties through the /field command, aligning with how properties are handled in other report elements. This ensures more reliable report generation.
Original PR description
Properties are not supported in ir.qweb but only as t-out, while t-field doesn't support them. For this reason and the fact that properties have a path the model field selector barely handles we do not allow those field to be selected in the /field command task-5999790
This update fixes an issue where selecting an office on the Jobs page would remove the previously applied country filter. The fix ensures that country filters remain active and functional when users select offices, improving the user experience for job searches. This change was made to ensure accurate filtering results.
Original PR description
Steps to reproduce: =================== 1. Navigate to the Jobs page. 2. Filter a specific country 3. Select all offices -> The country filter will be removed Cause: ====== the "All Offices" link inside job_filter_by_offices, the href uses 'all_countries=1' if is_remote else current_country_path but current_country_path is not defined anywhere Solution: ========= Switch to current_country_param Note: ===== The fix will be adapted in later versions opw-5947819 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252477
This update resolves an issue that occurred when users attempted to remove a company association from an expense record. The fix ensures the system handles company removal gracefully, preventing a technical error that could disrupt expense management. This improves the reliability of the expense tracking process.
Original PR description
Currently an error occurs when user tries to remove company on an expense. Steps to replicate: - Install `hr_expense` and create a new company. (make sure you have more than one company). - Create new expense and remove the value from company field. Error: `ValueError: Compute method failed to assign hr.expense(<NewId origin=7>,).is_editable` Cause: - Removing the company triggers the [compute] that skips the loop if company is not assigned [1], which causes this error. Solution: - Assign `is_editable` as False when company is false. [compute]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L304-L363 [1]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L326-L331 No ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241507
This update resolves an issue where changing the note on a food item after a quantity update would cause an error. The fix ensures that the note update process works reliably, preventing disruptions in order management within the POS system. This improves the overall user experience for restaurant staff.
Original PR description
**Steps to Reproduce:** - Install `pos_restaurant_preparation_display`. - Open Register for POS "**Restaurant**" Shop. - Choose table > select food-item > send the order. - Update food-item quantity > send the updated order. - Update food-item '**Kitchen Note**' > send the note. **Error:** `TypeError - 'NoneType' object is not subscriptable` **Cause:** When the food quantity is updated, a new preparation entry is created for the increased quantity. During the first iteration, the display and order quantities are already merged correctly. However, in a subsequent iteration, the original key no longer exists in `quantity_data`. As a result, accessing a None value leads to a traceback. **Fix:** This commit skips the merge step when the original quantity entry has already been merged. sentry-7197024946 Forward-Port-Of: odoo/enterprise#104889
This update resolves an issue where Odoo invoices for Danish customers were incorrectly formatted according to Peppol standards. The change skips adding redundant information to ensure compliance with regulations, preventing invoice submission errors. This ensures seamless integration with Peppol networks for Danish businesses.
Original PR description
Currently, if a Danish partner has a reference set, Odoo adds it under PartyIdentification. This violates Peppol `DK-R-013`, which mandates using schemeID when PartyIdentification is used. Adding the Danish schemeID would also trigger another error, `PEPPOL-COMMON-R042`, as the organization number (CVR) must be included in the `_text`. Including schemeID seem therefore unnecessary since it will appear in CompanyID. Steps to reproduce: - Create a Danish company and enable Peppol - Create a Danish customer with a reference - Create an invoice and submit to Peppol, `DK-R-013` error occurs opw-5921602 Forward-Port-Of: odoo/odoo#251737
This update removes an unnecessary check for local network connectivity when opening cashboxes via IoT. Because Stable IoT Boxes are now reachable through a websocket, this redundant step has been removed, streamlining the process. This change improves the reliability of cashbox operations.
Original PR description
Stable IoT Boxes can be reached using websocket, so it doesn't make sense to check the connectivity on local network before sending the "open cashbox" action. We then removed this check. Forward-Port-Of: odoo/enterprise#107397
This update fixes an issue where sandwich leave durations were incorrectly calculated when public holidays were involved. The fix ensures that all date calculations are properly localized to the company's timezone, guaranteeing accurate leave duration calculations for employees. This improves the reliability of leave management.
Original PR description
Steps to Reproduce: 1. Install the `l10n_in_hr_holidays` module. 2. Enable the "sandwich leave" option for the time off type. 3. Create public holidays that last the entire day, for example from 00:00 to 23:59. 4. Create a leave around the public holiday 5. Duration should be 3 days instead of 1 Cause: When creating a dictionary for company-specific public holidays, the dates from and to are not converted to the company's timezone when calculating the days between public holidays. Fix: To resolve this, the first step is to localize the `date_from` and `date_to` to the company's timezone before counting the days between the public holidays. Task-6012992 Forward-Port-Of: odoo/odoo#252466
A recent issue causing Distro builds to fail during the quality control tour has been resolved. The fix increases a delay in the tour process to ensure backend operations complete before the user interface updates, preventing UI elements from disappearing during the test. This improves the reliability of our automated testing environment.
Original PR description
Distro builds was failing with:
```js
FAILED: [8/14] Tour test_quality_check_packages_lots_tour →
Step .o_line_button.o_toggle_sublines
{
'trigger': '.o_line_button.o_toggle_sublines',
'run': 'click'
},
```
- This issue occurs due to a timing race condition in the barcode client action.
After scanning lots and clicking Put in Pack, backend calls are
still processing (updating move lines and packages) while the frontend re-renders the UI,
the tour continued before these operations were fully completed,
so the `.o_toggle_sublines` button was not yet available in the DOM.
This caused intermittent failures, mainly in slower CI environments like Distro builds/runbot.
- To fix this, the tour step_delay has been increased from 100 to 300,
giving enough time for backend processing and UI rendering
to complete before executing the next step.
---
runbot error:238452
Forward-Port-Of: odoo/enterprise#107766This update resolves an issue where users could incorrectly set both a start and end date simultaneously within the web_studio interface, leading to a validation error. The fix prevents this conflicting input, ensuring date range fields function as expected and improving data accuracy. This change impacts the usability of date-based fields in project configurations.
Original PR description
Steps to reproduce ================== - Install project,web_studio - Click on the three dots in the top right of a project - Click on settings - Open studio - Add a new date field - Set the start date field to Start date - Set the end date field to Expiration Date - Exit studio => The date range field is marked as invalid (red outline) Cause of the issue ================== https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/web/static/src/views/fields/datetime/datetime_field.js#L371-L373 We cannot set both the start and end field at the same time. opw-5403670 Forward-Port-Of: odoo/enterprise#108562
This update resolves an issue where incoming emails with attachments using the 'bin/plain' MIME type would cause the system to crash. The fix now gracefully handles this attachment type by converting it to a standard format, ensuring all emails are processed correctly and preventing disruptions to vendor bill creation.
Original PR description
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized. As a result,…
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized.
As a result, Python's email content manager raises KeyError('bin/plain') during parsing, which aborts the whole message processing. This prevents the incoming email from being processed, including vendor bill creation from email aliases.
Steps to reproduce:
- build an email with an attachment using Content-Type `bin/plain`
- parse it through `mail.thread.message_parse`
Before this commit, parsing crashes with KeyError('bin/plain').
This commit treats `bin/plain` like the other unsupported attachment MIME types already handled in stable, by falling back to `application/octet-stream`, allowing the message to be parsed and the attachment to be preserved.
opw-5439156
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251440This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (specifically, 2 payments instead of 4). This change improves the user experience by providing accurate information about the payment schedule. Additionally, the 'group payment' button is now correctly hidden when necessary.
Original PR description
[FIX] account: right number of payments skipped in send wizard Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/odoo#247830
This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (originally showing 4 when only the first installment was being paid). Additionally, a bug preventing the 'group payment' button from appearing under certain circumstances has been resolved. This ensures accurate payment tracking and a smoother user experience.
Original PR description
[FIX] account_iso20022: right number of payments skipped in send wizard adding tests to the community commit Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/enterprise#106894
This update fixes a bug in how scrap quantities are calculated for products. Previously, if a product didn't have a related Bill of Materials, the calculation would stop, leading to incorrect scrap quantities being reported. Now, all products are correctly processed, ensuring accurate scrap tracking.
Original PR description
### Description of the issue/feature this PR addresses: The `_compute_scrap_qty` method in **mrp/models/stock_scrap.py** exits early with return when a record has no BOM, preventing the computation of `scrap_qty` for remaining records in the recordset. ### Current behavior before PR: When iterating over a multi-record recordset, if any record lacks a `bom_id`, the method does return `super(...)._compute_scrap_qty()`, which exits the entire loop. Records after that one are never computed and keep the default value of 1. ### Desired behavior after PR is merged: Records without a `bom_id` delegate to `super()._compute_scrap_qty()` and the loop continues (continue) to the next record, ensuring all records in the recordset are properly computed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252149