Wednesday, March 25, 2026
16 changes · 18.0
Enhancements to existing features
This update ensures that invoice tax information displays the correct label, aligning with the tax's defined 'invoice_label' field. This is particularly important for accurate tax reporting in different regions where invoice labels may not match internal tax names. The change improves the clarity and accuracy of invoices.
Original PR description
When computing taxes for invoice lines, the system should use the `invoice_label` field instead of the default `name` field to display tax information. This allows invoices to show more appropriate…
When computing taxes for invoice lines, the system should use the `invoice_label` field instead of the default `name` field to display tax information. This allows invoices to show more appropriate tax labels that may differ from the internal tax name. Technical details: - Added `is_invoice` context when calling `tax_ids.compute_all()` in `account.move.line._compute_all_tax()` method - Modified `account.tax.compute_all()` to check for `is_invoice` context and select appropriate field name (`invoice_label` for invoices, `name` for other documents) - The selected field name is used when building the tax values dictionary returned by `compute_all()` This change ensures that invoice tax lines display the correct label as defined in the tax's `invoice_label` field, which is particularly useful for localized tax reporting requirements where the invoice label may differ from the internal tax name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236497
Resolved issues and error corrections
This update resolves an issue where fields weren't being populated correctly when new records were created in certain Odoo modules. The fix ensures that fields are properly filled in during the creation process, improving data accuracy and reliability. This primarily impacts HR and reporting functionality.
Original PR description
See https://github.com/odoo/odoo/pull/199647. Forward-Port-Of: odoo/enterprise#109725
This update fixes a discrepancy in how tax reports are tested within Odoo. The change ensures tests now correctly utilize the 'invoice_label' field for tax information, rather than the 'name' field. This improves the accuracy and reliability of tax report generation across various Odoo localization modules.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/236497 Forward-Port-Of: odoo/enterprise#103555
This update resolves a compatibility issue with the website knowledge editor's HTML migrations. The change utilizes a more widely supported selector (`selectorHas`) instead of `:has`, ensuring consistent functionality across different browsers. This improves the stability and reliability of the knowledge base feature.
Original PR description
The `:has` selector is not yet fully supported by `querySelectorAll` in all browsers. Public widgets have the `selectorHas` attribute to get arround this. opw-4658698
This update removes a confusing purple pill that appeared on mobile devices when using Web Studio. This prevented users from easily clicking action buttons, leading to a frustrating experience. The change ensures a cleaner and more intuitive interface for mobile users.
Original PR description
Steps: - Install `web_studio` - Add an approval rule to any action in any form view (example preview button) - Open this form view - You will have a purple info pill in every action button in the form view This can be confusing for people wanting to click on the button on mobile but instead, they click on the purple pill + we don't even want this opw-5911667
This update resolves an issue where saving a report with an empty XML format in Web Studio would generate an error. The fix prevents the system from attempting to process invalid XML data, ensuring reports can be saved correctly. This improves the user experience and prevents data corruption.
Original PR description
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External…
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External > Type Text in report - Save > Edit Sources > Remove full XML > Save Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)` This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error. In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow `view.arch` to be empty. As a result, this error is no longer handled by the constraint. This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available. [1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367 [2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377 [3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f sentry-6288795955
This update fixes a previous issue where the data merge process would fail silently if it timed out. Now, users will receive a warning notification, and the system suggests merging fewer records for a smoother experience. Reloading the model on successful completion ensures data accuracy.
Original PR description
Display a warning notification when the merge operation times out instead of failing silently. Suggest merging fewer records and reload the model on success. task-5912855 Forward-Port-Of: odoo/enterprise#110763
This update fixes an issue where the canteen cost was incorrectly calculated for Belgian employees, even when they had no attendance recorded. The fix ensures the canteen cost is only applied if the employee has earned money through attendance or working during the payslip period, preventing incorrect charges.
Original PR description
[FIX] l10n_be_payroll: fix canteen cost computation
Bug reproduction: belgium company -> create a new employee -> new contract (payroll wage > 0) -> canteen_cost = 50 -> create payslip -> allocate time off for full month (such that there will be no attendance) -> recompute payslip -> still canteen cost is calculated
Bug cause:
1 - If l10n_be_canteen_cost is > 0 it was computing the canteen cost line for sure
2 - If result_rules['BASIC']['total'] is > 0 then the canteen cost was 50.
Bug solution:
1 - I add worked_days['WORK100'].amount != 0 to the computation condition.
2 - If there is any earned money from attendance or working in that payslip duration, the canteen cost should be deducted completely
3 - If the employee is absent during the payslip, the employee should not pay the canteen cost.
task - 6045406
Forward-Port-Of: odoo/enterprise#110991This update fixes an issue where duplicating a product template in Odoo would automatically publish the duplicate, even if the original wasn't. The change ensures that duplicated product templates remain unpublished by default, aligning with expected behavior and preventing unintended product listings. This improves data consistency and reduces potential errors.
Original PR description
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a…
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a eCommerce category. 2- Without publishing the product duplicate it. Even though the original product is not published, the duplicated one is published. Expected: Regardless of published state of original product, the duplicated product should not be published. Cause: --- This regression is introduced in https://github.com/odoo/enterprise/pull/66218 to create a `is_published` product if `public_categ_ids` is set. However this was only supposed to be when creating a new product using form. It makes the create to ignore `is_published` default value even in copy. Fix: --- We can make sure if `is_published` is in create vals, don't force `is_published` to be set True. However, as `copy=False` in `is_published` field definition, it won't be in vals in copy. By overriding `copy_data`, we can ensure vals is present in copy. #### Note: `product_barcodelookup` doesn't depend on `website_sale`. However, `product_categ_ids` is used in this module. In the test for the same case we only run the test if the module is installed. This would be fine as this is a post-install test. opw-6014789
This update fixes an issue where the external value pop-up consistently used a dot as the decimal separator, regardless of the user's language settings. Now, the pop-up will display the decimal separator appropriate for the user's locale, ensuring accurate reporting and a better user experience across different languages.
Original PR description
Description of the issue this commit addresses: The external value pop up doesn't take into account the locale to chose which decimal separator to use. --- Desired behavior after this commit is merged: The decimal separator is the one determined by the language of the user rather than always a dot. --- task-6010533 Forward-Port-Of: odoo/enterprise#109948
This update resolves an issue preventing the Spanish SII demo environment from functioning correctly. We've implemented a working demo using the AEAT test environment, ensuring it accurately reflects the required SII processes. Importantly, the VAT number remains unchanged in the demo company, maintaining data consistency.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a problem where receipts generated for multiple orders were using the same QR code, leading to incorrect invoice references. The fix ensures that each order receives a unique QR code image, improving the accuracy of printed receipts. This resolves a potential issue with order tracking and data integrity.
Original PR description
**Step to reproduce:** - install "l10n_es_edi_verifactu_pos" - setup "ePOS printer" for a pos - open pos and settle a order below 400$ - notice we get l10n_es_edi_verifactu_qr_code in our receipt -…
**Step to reproduce:** - install "l10n_es_edi_verifactu_pos" - setup "ePOS printer" for a pos - open pos and settle a order below 400$ - notice we get l10n_es_edi_verifactu_qr_code in our receipt - click on "Print receipt" - repeat above steps for one more order **Observation:** - when we print the second order receipt, the QR still points to 1 order invoice **Issue:** - [getCacheKey](https://github.com/odoo/odoo/blob/0cee3350df09b06af77c879f0eba74bf6a8dd2c9/addons/point_of_sale/static/src/app/utils/html-to-image.js#L351C10-L355 ) was trimming query strings when generating cache keys. URLs like: ` http://localhost:9000/report/barcode/?barcode_type=QR&value=... ` were reduced to: ` http://localhost:9000/report/barcode/` - As a result, different QR code requests shared the same cache key. Subsequent requests reused the previously cached image instead of fetching a new one, producing incorrect QR codes for different orders. **Solution:** Add an `includeQueryParams` flag to `resourceToDataURL` so the full URL, including query parameters, is used as the cache key when needed. This ensures unique QR code URLs are cached and fetched correctly. opw-5455807 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251139
This update replaces the old iDEAL logo with the new Wero logo for improved brand consistency. This change ensures that customers see the correct branding when using the iDEAL payment method within Odoo. It’s a minor update to the payment method’s visual appearance.
Original PR description
Before the commit: The iDEAL payment method was using the existed legacy iDEAL logo. After the commit: - Updated the display name to "iDEAL / Wero". - Replaced the legacy iDEAL logo with the new Wero logo. - Introduced a separate "Wero" payment brand. task-5922938 Forward-Port-Of: odoo/odoo#248506
This update resolves an issue where the coupon form was hidden when a pricelist included an 'E-commerce Promotional Code'. The fix maintains a temporary setting to prevent disruption to existing functionality while the underlying cause is addressed. This ensures consistent coupon form visibility for all users.
Original PR description
Issue: --- If the current pricelist has `E-commerce Promotional Code` set, the coupon form is hidden. Steps to reproduce: --- 1- Create a pricelist and set `E-commerce Promotional Code`. 2- Navigate to the cart in website. 3- Enter pricelist code in the coupon form. Result: Once the code is entered, pricelist is changed and the coupon form is hidden. Cause: --- This is done intentionally on #23713. However, it seems it's not relevant anymore. Fix: --- We can remove `force_coupon` condition from `reduction_code` template. However `force_coupon `is also used inside xpath expression in `reduction_coupon_code` template. In order not to break stable we can keep `t-set="force_coupon"` inside the `reduction_code` template, and remove it on master. opw-5977474
This update resolves an issue where users would encounter an error when attempting to save reports with empty XML formats. The fix prevents the system from attempting to process invalid XML data, ensuring reports can be saved correctly. This improves the user experience and prevents data corruption.
Original PR description
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External…
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External > Type Text in report - Save > Edit Sources > Remove full XML > Save Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)` This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error. In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow `view.arch` to be empty. As a result, this error is no longer handled by the constraint. This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available. [1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367 [2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377 [3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f sentry-6288795955 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update streamlines Odoo's testing process by proactively generating bundled resources. Previously, these resources were created on-the-fly during tests, causing delays. Now, the system identifies and pre-generates these bundles, resulting in faster and more reliable test execution.
Original PR description
tl;dr: look for lazy loaded bundles and add them to the bundles' list to pregenerate before running tests to avoid generation on the fly. Forward-Port-Of: odoo/odoo#248256