Friday, April 17, 2026
15 changes · 18.0
Resolved issues and error corrections
This update resolves an issue where ISO20022 payments using JPY were failing due to a hardcoded decimal format. The fix dynamically adjusts the amount format to match JPY's zero-decimal currency, ensuring compatibility with banking systems. This prevents payment failures and improves the reliability of JPY transactions.
Original PR description
Steps to reproduce: ------------------- 1. Activate JPY and create a JPY bank journal with ISO20022 as an outgoing payment method 2. Create a vendor (with a country) and add a trusted bank account 3.…
Steps to reproduce: ------------------- 1. Activate JPY and create a JPY bank journal with ISO20022 as an outgoing payment method 2. Create a vendor (with a country) and add a trusted bank account 3. Create and confirm a vendor bill in JPY (e.g. ¥1000), and pay it using the ISO20022 method on the JPY journal 4. Create a batch payment containing that payment, with Batch Type Outbound, on the JPY journal, with ISO20022 as payment method 5. Validate the batch — the XML file is generated and attached 6. Download it -> The `<InstdAmt Ccy="JPY">` node outputs `1000.00`, while JPY has no decimals. The file is rejected by banks. The fix: -------- Backport of 8da91d94ed1e8fad0e827f96172e3785e9f0e28d: > Generating the xml file for iso20022 always generates the amount with two decimals which is hard coded and can cause error for currencies without decimals for example JPY. > The fix is to have the currency decimal number dynamically set through the currency decimal places field. opw-6103849
This update fixes an issue with invoice rounding related to down payments in the account_edi_ubl module. The system now correctly uses specific currency values to ensure the total invoice amount matches expected calculations, particularly when dealing with initial payments. This improves invoice accuracy and prevents discrepancies.
Original PR description
'total_excluded_currency' is for the base amount. 'base_amount_currency' should be used only when getting the base per tax. When dealing with a down payment, a distortion in the taxes amounts might be introduced to ensure the total of the invoice is exactly the expected one. opw-6120645 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the Mercado Pago webhook couldn't process invoices with references containing slashes (like INV/2026/00001). Previously, the system would return an error. This change ensures that all invoice references, including those with slashes, are correctly processed by the webhook, improving integration with Mercado Pago.
Original PR description
Currently, the mercado_pago_webhook http route only takes into consideration 1 url segment. This means that invoices with references like INV/2026/00001 don't match any defined route and the server returns a 404. /payment/mercado_pago/webhook/S00001 => OK /payment/mercado_pago/webhook/INV/2026/00001 => KO This commit allows references with slashes to be matched by the route by capturing the entire remaining url path including the slashes. /payment/mercado_pago/webhook/S00001 => OK /payment/mercado_pago/webhook/INV/2026/00001 => OK opw-6035161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259378
This update resolves an issue where invoice creation would fail when the 'aggregate' setting was enabled without a defined 'aggregate period'. The change ensures that a valid 'aggregate period' is always required when 'aggregate' is set, improving invoice processing stability.
Original PR description
Previously, if `is_aggregate_limit` was set to True while `aggregate_period` was left empty, it would raise a traceback during invoice creation. Although `aggregate_period` has a default value, it can still be manually cleared. With this commit, `aggregate_period` is enforced as mandatory whenever `is_aggregate_limit` is enabled, preventing such errors.
This update corrects and streamlines French translations for the Enterprise module, specifically for asset and reporting functionalities. Incorrect or outdated translation overrides have been removed, ensuring consistent and accurate language across French-speaking regions (Belgium and Canada). A minor menu item adjustment was also made for the Netherlands.
Original PR description
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#106998
This update resolves a test failure related to a calculated field in the Belgian payroll module (l10n_be_hr_payroll). The fix removes tracking from a specific field, preventing it from being prematurely computed during test runs. This ensures accurate calculations and reliable test results.
Original PR description
…ield The computed, non-stored field `l10n_be_holiday_pay_recovered_n1` had tracking enabled. When writing to any field on the employee, the `write` method calls `_track_prepare` for tracked fields if `mail_notrack` is not set in the context. `_track_prepare` reads the current value of tracked fields to store initial values. Because `l10n_be_holiday_pay_recovered_n1` is non-stored with no dependencies, this triggered a computation at the very beginning of the test, before payslips existed. Later, when payslips were created, the field was never recomputed, causing incorrect values and test failures. Previously, the `tracking_disable` context prevented early computation. The fix removes the tracking attribute entirely, so the field is only computed when accessed, avoiding premature reads and fixing the tests. task: 6095445 Forward-Port-Of: odoo/enterprise#113015
This update fixes a display issue in grouped list views where the pager incorrectly showed the `count_limit` instead of the total record count. The change ensures the pager accurately reflects the number of records in a group, improving user experience and data accuracy. This was achieved by leveraging existing calculations within the system.
Original PR description
When a pager is needed in a grouped list view and if the total number of record is greater than the `count_limit` (by default equal to 10000); opening the group or pressing the "Next" button will display the `count_limit` in the Pager.
This behavior can be optimized since the `web_read_group` call already computed the total count.
This commit allow the grouped list pager to display the total record count if it was already computed.
Steps to reproduce:
in a list view with 10 records, all in the same group for simplicity:
```xml
<list limit="2" count_limit="8">
<field name="foo"/>
</list>
```
- group the view by "foo" => The pager displays: `"1-2 / 10"`
- click on the 'next' button of the pager => The pager displays: `"3-4 / 8"`
8, the `count_limit` is shown instead of 10, the number of records in the group.
task-6053705This update corrects a technical problem where the cookies bar's state was incorrectly saved, leading to performance issues and potential errors with website responses. The fix prevents the cookies bar from persistently setting an invalid value, ensuring a smoother user experience and preventing issues with website delivery.
Original PR description
Steps to reproduce: - Set the cookies bar - Do not accept nor reject it - On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set. `Popup`…
Steps to reproduce: - Set the cookies bar - Do not accept nor reject it - On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set. `Popup` initializes `cookieValue` to `true` and writes it in `onHideModal()`. If the cookies bar is closed before any explicit consent choice, it can therefore recreate the legacy invalid value `website_cookies_bar=true`. This happens because the search button uses `data-bs-toggle="modal"`, which is controlled by Bootstrap: if it is opened while another bootstrap modal is already open on the page, the latter is hidden. This in turn calls the popup interaction's `onHideModal()`, which sets `website_cookies_bar=true` as `cookieValue` hasn't been changed. That value is later treated as invalid and cleared repeatedly during website rendering, which can accumulate duplicate `Set-Cookie` headers in the same response and lead to `upstream sent too big header` behind nginx. Avoid persisting that legacy value by returning early from `CookiesBar.onHideModal()` while `cookieValue` is still the inherited default `true`. opw-6037573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Backport of: https://github.com/odoo/odoo/pull/258938 Forward-Port-Of: odoo/odoo#259585
This update resolves a problem with a test case in the Helpdesk Stock module. The test was referencing a field that didn't exist in the Helpdesk Stock module, causing test failures. This change ensures the tests accurately reflect the functionality of the Helpdesk Stock module.
Original PR description
Remove sale_line_id field from the test as it belongs to helpdesk_sale_timesheet and is not available in this module. runbot link - https://runbot.odoo.com/odoo/runbot.build.error/242470
This update fixes a misconfiguration in the Philippine localization (l10n_ph) module. The '12% I' tax group was incorrectly categorized as 'Capital 12%'. This change ensures accurate VAT reporting and compliance with Philippine tax regulations. It's a necessary correction for proper financial reporting.
Original PR description
In this commit: - We change the group of tax '12% I', from 'Capital 12%' to 'VAT 12%' task-6092566
This update fixes an issue where tax reporting for '12% I' was incorrectly displayed under 'Purchase of Capital Goods' in Philippine sales reports. The change now accurately shows this tax amount under 'Purchase of Other than Capital Goods', ensuring correct financial reporting for Philippine businesses using Odoo Enterprise.
Original PR description
Before this commit: - The amount of tax '12% I' is shown under 'Purchase of Capital Goods'. After this commit: - The amount of tax '12% I' is shown under 'Purchase of Other than Capital Goods'. task-6092566
This update resolves a bug where users lacking sufficient permissions encountered errors when modifying sales order lines within subscription timesheets. The fix involves a simplified data fetch to prevent privilege-related access issues, ensuring smoother operation for users with limited access.
Original PR description
The change in e75bc6a1fac056d72fe9e73513635f9e0ba7db22 may cause some access errors when the user don't have the proper privileges. STR: 1. Having a user (demo) with minimal permissions: sales own documents, timesheets and project user 2. Having a sales order for customer that demo user can read with services in it. 3. Having that customer a task with a sale that the demo user can't read. 4. When the user tries to change the line to one that he can actually read, an error raises. The display_name function tries to fetch data from the lines related order. Let's just sudo that fetch to avoid these kind of issues. A demo video: https://www.loom.com/share/ddd02d72bcea4652b79549aba47d5334 opw-5969767 cc @moduon MT-14483
This update resolves an issue where invalid Taiwan VAT numbers (e.g., containing letters) would cause the invoicing system to crash. The fix adds validation to ensure VAT numbers contain only digits, preventing the error and providing a clear warning message to the user. This ensures data integrity and a smoother user experience when entering customer information.
Original PR description
**Steps to reproduce:** - Install the `base_vat` module. - Navigate to Invoicing > Customers. - Create a new contact and set the country to `Taiwan`. - Enter `1234567A` as the `Tax ID` and try to `save`. **Error:** `ValueError: invalid literal for int() with base 10: 'A'` **Root cause:** At [1], `check_vat_tw` is missing validation to ensure that the VAT number (without the country code) contains only digits, which causes an error when calling the `int()` method on the VAT number. **Fix:** This commit prevents errors and ensures users receive a `clear warning message`. [1]: https://github.com/odoo/odoo/blob/23398d24e108875b2838715d4b366df265d53234/addons/base_vat/models/res_partner.py#L929-L958 **No task Id** Forward-Port-Of: odoo/odoo#259847
This update fixes a potential issue during module uninstalls. Previously, outdated references within the Odoo system could cause errors in subsequent operations. Now, the system clears all relevant caches to ensure accurate tracking of field objects, leading to more reliable module uninstalls.
Original PR description
When uninstalling a module, the ORM may replace field objects in the registry via a prefetch patch to avoid fetching deleted fields. The previous code only called lazy_property.reset_all(), which resets lazy-property caches, but left _field_trigger_trees and _is_modifying_relations intact. Those structures still held references to the old field objects, and could be consulted by subsequent ORM operations, leading to incorrect trigger resolution or relation tracking. Clear both caches whenever a shared field has been patched so all registry state stays consistent with the new field objects. runbot-242251 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 Forward-Port-Of: odoo/odoo#259820
Features or functions removed from Odoo
This update removes a confusing tooltip from the 'tax_scope' field in the accounting module. The tooltip incorrectly suggested this field restricted taxes by product type, which wasn't true. This change clarifies the field's function and improves user understanding.
Original PR description
The current tooltip suggests that the `tax_scope` field restricts the use of taxes based on the product type. However, this is misleading, as the field does not enforce any restriction at the product level. To avoid confusion, remove the tooltip entirely. Backport of: https://github.com/odoo/odoo/pull/256573 opw-6118051 Forward-Port-Of: odoo/odoo#259550