Daily updates from Odoo
Friday, April 17, 2026
10 changes · 17.0
Resolved issues and error corrections
This update fixes an error in how stock valuations are calculated when receiving foreign currency purchases with auto-standard products. Previously, incorrect currency exchange entries were created, leading to inaccurate inventory values. This change ensures that stock valuations accurately reflect the cost of goods, regardless of currency.
Original PR description
This is a backport of https://github.com/odoo/odoo/pull/243029 The same bug is reproducible in 17.0 Processing a buy-receive-bill process in a foreign currency and with an auto-standard product will…
This is a backport of https://github.com/odoo/odoo/pull/243029 The same bug is reproducible in 17.0 Processing a buy-receive-bill process in a foreign currency and with an auto-standard product will lead to an incorrect valuation To reproduce the issue: (Company in USD) 1. Enable EUR and define the rates as followed: - Yesterday: 2 - Today: 2.5 2. Create a product category: - Method: Standard - Valuation: Automated 3. Create a product P in that category - Cost: 10 USD 4. [Yesterday] Confirm a PO in EUR with 1 x P 5. [Yesterday] Receive it 6. Bill Error: the stock valuation has two entries: one with 10 USD debit, the receipt. Another one with 2 USD credit, the currency exchange rate difference. The second one is a mistake, in a standard configuration, the stock valuation should be impacted by nothing but the cost defined on the product form. Since https://github.com/odoo-dev/odoo/commit/bae7feefcb08db7329d52bc36517dfd73f3347a7, in some conditions the method `_get_exchange_account` returns the stock valuation account. This is what happens here, but it's a mistake since in the above case, we should stick with the classic account (i.e. the `super` call). The conditions must be more strict. opw-5905197
This update fixes an issue where the Italian tax module was incorrectly removing parts of VAT numbers when generating XML invoices for Spanish partners. The fix ensures that VAT numbers, like 'A95758389', are accurately exported to the tax agency, preventing data discrepancies and potential compliance problems. This improves the reliability of invoice data transmission.
Original PR description
**Steps to reproduce:** * Install `l10n_it_edi` module. * Create a partner with country **Spain** and VAT `A95758389`. * Create an invoice and send it to the Tax Agency, and download XML. **Observed behavior:** * The exported XML contains `5758389` in <IdCodice> instead of `A95758389` — the first two characters of the VAT are silently dropped. **Cause:** * In `_l10n_it_edi_get_values`, the EU branch that strips the country-code prefix used a bare `else` after the `isdecimal()` check, unconditionally removing the first two characters of any VAT that does not start with two digits. Spanish NIFs like `A95758389` start with `A9` (letter + digit), which is not a country-code prefix but was treated as one, corrupting the value. **Fix:** * Remove country prefix from normalized VAT by `removeprefix(normalized_country)` Instead of removing the first two characters. It will ensure that only the country prefix will be removed. opw-6089198
This update resolves a test issue causing inconsistent results in the web_editor's link popover functionality. The fix ensures the selection is correctly set after a click, mirroring a user's actual interaction. This improves the reliability of the test and the overall stability of the web_editor module.
Original PR description
The popover opening is triggered through click, but there is a selectionchange handler on click that checks if the selection is outside of the link and, if it is, closes the popover. In this case, the click method didn't set the selection inside the link properly because of the presence of \ufeff around the link. The test actually passes by mistake when the runbot was fast, but failed when the runbot was slow, as the selectionchange handler had the time to execute and close the popover. This commit forces the selection to be inside the link after calling click, to be closer to what actually happens when a user click on a link, as opposed to a programmatic click. runbot-161423
This update corrects a bug where a refund payment was automatically generated when an uncaptured Stripe payment was voided. This prevented incorrect financial reporting and ensured accurate transaction tracking. The change avoids unnecessary refund processing for payments that haven't been collected.
Original PR description
When an uncaptured Stripe payment is voided, the system will still generate the refund payment entry. Steps to reproduce: - Configure the Stripe payment provider - enable "Capture Manually" - generate webhook - Create a sales order - Generate a payment link and pay with Card - Back to the SO, click 'Void Transaction' Issue: Refund payment entry will be created even if no payment has been collected for the transaction. opw-5866924
This update fixes a minor inefficiency in the process of importing invoices from XML files. Previously, the system unnecessarily re-searched for products, even after a successful search. This change ensures the import process is more efficient and responsive, reducing potential delays.
Original PR description
### Description: Following this commit[^1], parts of the import of invoices from XML files was improved and batched. However, the logic used to filter products that has been searched was flawed: it checked if a product had already been found, rather than if a search had already been attempted. This caused the code to still trigger a search even if it has been executed previously with the same parameters. ### Reference: opw-5462267 [^1]: 2ca1ebac8d4b026e58c4373a346244b086425ff3
This update corrects a problem where invoice exports to FAIA were failing due to inconsistencies in how account IDs were referenced. The change ensures that all account IDs in the export match those defined within Odoo's accounting system, improving the reliability of financial reports. This resolves an issue impacting accurate reporting.
Original PR description
This is one of several commits fixing the FAIA xml export. The Invoice/Line/AccountID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match an account defined in MasterFiles/GeneralLedgerAccounts/Account/AccountID. As the latter uses account_code since PR #65221, the former should too. opw-5427296 [Link](https://www.odoo.com/odoo/unassigned-tasks/5427296)
This update resolves an issue where entering an invalid Taiwan VAT number (e.g., containing letters) would cause the invoicing system to crash. The fix adds validation to ensure the VAT number consists only of digits, providing a clear warning message to the user instead of an error.
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**
This update resolves an issue that could cause incorrect behavior after uninstalling modules in Odoo. Previously, uninstall processes didn't fully clear outdated data, leading to potential errors. Now, the system ensures all relevant caches are cleared, guaranteeing a cleaner and more reliable uninstall experience.
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
This update fixes an issue where the web interface could crash when retrieving data due to outdated cached information. The change ensures a safer and more reliable way of filtering x2many records, aligning the system with recent improvements and preventing potential errors. This enhances overall web performance and stability.
Original PR description
Description of the issue/feature this PR addresses: This is a follow-up to #250904. The original 17.0 fix filtered inaccessible x2many records reused from cache during web_read. However, while…
Description of the issue/feature this PR addresses:
This is a follow-up to #250904.
The original 17.0 fix filtered inaccessible x2many records reused from cache during web_read. However, while forward-porting the fix to 18.0, additional issues were revealed.
The original issue is still cache pollution: web_read may reuse cached x2many ids that are not accessible anymore with the current record rules/context, and should neither expose them nor crash when formatting the result.
The 18.0 investigation showed that the first approach was not enough in all cases:
* using search([('id', 'in', ...)]) to filter x2many records is not always safe, as some models can override search() and raise errors
* using _filtered_access('read') unconditionally can also be too aggressive when the current user has no general read access on the comodel, as it may remove valid x2many values and break existing flows.
This PR backports the adjusted logic from the 18.0 forward-port to 17.0, so that 17.0 stays aligned with the later versions.
Current behavior before PR:
Even after the previous fix, web_read can still mishandle polluted cached x2many values in some cases, either by crashing while trying to filter/order the records, or by over-filtering them when the user has no general read access on the comodel.
Desired behavior after PR is merged:
web_read should keep filtering polluted x2many values when the user has read access on the comodel, while avoiding regressions for fields whose comodel is not generally readable by the current user.
The x2many values are therefore filtered in a safer way, aligned with the logic introduced in the 18.0 forward-port.
Backport-Of: #257517
X-original-commit: 05ded3eda89fb8ff9aafa62f314a9d5d4677d292 (cherry picked from commit 7eec72aadc294b1c2780e601e81636cffcc4965d)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFeatures 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 isn'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