Daily updates from Odoo
Thursday, February 12, 2026
15 changes · 17.0
Enhancements to existing features
This update introduces a time limit for profiling queries within Odoo. Previously, profiling could run indefinitely, consuming resources. Now, queries are automatically timed and reported, providing more efficient monitoring and helping to identify performance bottlenecks.
Original PR description
Modify the query collector so that it add an entry before the query runs and updates the time after it runs. use the async collector periodic sampling to commit the profiler after a time limit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update streamlines the process of generating account reports by eliminating a less efficient query. This change improves the speed and reliability of generating key financial reports, leading to faster insights for our finance team. The update focuses on internal performance improvements.
Resolved issues and error corrections
This update fixes a visual issue in the Italian tax module where the TC-XX codes for pension funds weren't displayed alongside the fund names. Previously, all other selection fields showed codes first, but this field was an exception. This change ensures consistent and clear presentation of tax information for Italian businesses.
Original PR description
How to reproduce: - Install the l10n_it_edi module - (Create and) switch to an Italian company - Go to the form view of any tax - In Advanced Options, click on the Pension fund type field The problem: The codes are not displayed before the names of the pension fund types Why: All other selection fields in the Advanced Tab shows the code before the name (Exemple: Tax category code, Exoneration, ...). The Pension fund types field was the only one that did not opw-5914302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes a redundant parameter from the Italian VAT reporting system (l10n_it_edi). The parameter was not being used in the API and caused confusion for developers. This change simplifies the system and improves its stability.
Original PR description
Juyt remove the `recipient_codice_fiscale` parameter for the request to the SdI, as it is not used in the API. It just creates confusion for the people who are debugging.
This update fixes an issue where the duration of quickly created calendar events wasn't accurately reflected after manual adjustments. The change ensures that the displayed event duration always matches the intended length, improving event planning accuracy. This aligns the calendar functionality with recent updates in Odoo 19.
Original PR description
Currently, an incorrect duration is displayed when the start or end time is `manually changed` during event creation. **Steps to reproduce:** - Install the `Calendar` module and open the app. - Drag…
Currently, an incorrect duration is displayed when the start or end time is `manually changed` during event creation. **Steps to reproduce:** - Install the `Calendar` module and open the app. - Drag on the calendar to create a `2-hour` time slot (quick-create popup opens). - Manually adjust the start or end time to make the event `3 hours` long. - Click `Save & Close`. - Click on the event: it correctly displays (3 hours). - Click `Edit` and observe the `Duration` value. **Observation:** The duration field shows 2 hours instead of 3 hours. **Root cause:** - The `duration` field is not available (and therefore not stored) in the `quick-create view` at [1]. - When the `stop` time is set manually, the `duration` is computed at [2]. - When the `start` time is changed, the `stop` time is computed based on the previously computed `duration` at [3]. **Fix:** This commit adds the `duration` field to the `quick-create` view as `invisible` (preventing it from being recomputed on each onchange) and `force_save`. This aligns the behavior with `19.0` by preserving the last computed duration in the front-end model, as implemented in PR [4]. [1]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/views/calendar_views.xml#L294-L339 [2]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/models/calendar_event.py#L353-L356 [3]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/models/calendar_event.py#L358-L374 [4]: https://github.com/odoo/odoo/pull/226909 opw-5867946
This update resolves an issue where importing EDI invoices could fail when products were restricted to a different company. The fix ensures products are correctly identified during import, preventing 'Incompatible company' errors. This improves the reliability of EDI invoice processing within multi-company Odoo environments.
Original PR description
In a multi-company environment, importing an EDI invoice could fail if a line contains a product restricted to another company. The error "Incompatible company on records" was raised because company consistency rules were applied.
Example steps to reproduce:
- Create two Italian companies, A and B
- In company A, create a product with default code or barcode "TEST"
- This can also occur using the barcode and the “Vendor Product code” from the Purchase supplier.
- Restrict this product to company A
- Create an EDI invoice in company A with this product for company B as customer
- Import the invoice in company B, which would fail
This fix adds a search domain to correctly find products during import
opw-5496912This update fixes an issue where invoices created in foreign currencies didn't accurately display the amount in the company's local currency when generating reports. The fix ensures that amounts are correctly rate-adjusted, providing accurate financial reporting for Saudi Arabia companies. This improves the reliability of financial data.
Original PR description
After 267a876451da8b39ab8c5885e7198ebfeb841573 invoice report will not show the correct amount in company currency Steps to reproduce: - With SA Company setup - Create invoice in foreign currency - Print Issue: Amount in company currency have not been rate adjusted. This occurs because amount_untaxed and amount_total are expressed in foreign currency. 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 bug that occurred when users entered non-numeric values in the 'Number of SN' field during serial/lot number generation. By changing the input field to only accept numbers and adding a check for periods, the system now gracefully handles invalid input, preventing tracebacks and ensuring reliable serial number creation.
Original PR description
Issue before this commit: ========================= When generating serial/lot numbers, if a user enters a `string value (e.g. "dhha" or ".")` in the `Number of SN` field of the Generate Serials/Lots…
Issue before this commit: ========================= When generating serial/lot numbers, if a user enters a `string value (e.g. "dhha" or ".")` in the `Number of SN` field of the Generate Serials/Lots wizard, a traceback is raised: `InvalidNumberError: "dhha" is not a correct number`. Steps to Reproduce: ========================= - Install the "stock" module. - Create a receipt for a serial-tracked product. - Open the detailed operations. - Click on "Generate Serials/Lots". - Enter a string value in the "Number of SN" field. Result: A traceback is raised with: InvalidNumberError: `"dhha" is not a correct number.` Cause of the issue: ========================= The [next_serial_count input](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/lots_dialog.xml#L36) field is defined as type="text", which allows users to enter string values, even though the field represents a numeric count. The value is later processed using [parseInteger](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/generate_serial.js#L33), which throws an error when the input is not a valid integer string, [Here](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/fields/parsers.js#L139). With This Commit: ========================= The input type is changed from type="text" to type="number", ensuring that only numeric values can be entered. This prevents invalid input and avoids the traceback when generating serial or lot numbers. Additionally, a `t-on-keydown` handler is added to prevent entering a `dot (.)`, ensuring that only integer values are allowed.
This update corrects a reporting error in the Spanish VAT (l10n_es) module. Previously, the 'mod 390' report displayed the same vendor bill amount twice. The issue stemmed from an incorrect tax template definition for 0% EU G transactions, now resolved to ensure accurate reporting.
Original PR description
How to reproduce: - Install the l10n_es module - Switch to a spanish company - Confirm a Vendor Bill with a Product with the tax 0% EU G - Go to the Tax Report and select mod390 The problem: In the section "Adquisiciones intracomunitarias de bienes", the total amount is shown two time, once for grid 716 and once for grid 26 Why: In the declaration of the tax template for 0% EU G, there is two tags for the mod 390, the one for grid 26 being wrong Before: <img width="818" height="447" alt="image" src="https://github.com/user-attachments/assets/0565802d-5d98-4e0f-9e08-50776f0a5aec" /> After: <img width="834" height="443" alt="image" src="https://github.com/user-attachments/assets/89696c83-7022-439d-adaa-d456c2dbadf8" /> opw-5867849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing a key website test from running correctly. The test required a specific user group to be enabled, which was only necessary when running with the demo environment. This change ensures the test now works consistently regardless of the environment, improving testing reliability.
Original PR description
Commit f86f6f6a3dc6bbeb8c68308aab2462b9c7bb935d (6th February 2026) added the test test_website_force_domain_redirect but it doesn't work without demo data because it was requiring "website.group_multi_website" group to be enabled. Fix: add the group for the test case in case it's not enabled. runbot-[238897](https://runbot.odoo.com/odoo/runbot.build.error/238897) opw-5441957 Note: this was noticed in saas-18.3 forward port so this is only necessary up to saas-18.2 version.
This update corrects a technical issue where Odoo incorrectly identified nodes with directives (like 'groups') as translatable. This prevented proper translation of certain elements within the user interface. The fix ensures that only elements without directives are considered for translation, improving the accuracy of translated content.
Original PR description
Nodes with directives must not be included inside a translatable span. But the function `translatable` missed the directive `groups` (without `t-`), and the class `o_translate_inline` should only override the predicate about the element's tag.
This update corrects an issue where a proforma vendor bill was incorrectly displayed when accessing or downloading bills through the customer portal. The fix restricts proforma bills to invoices and credit notes, ensuring users receive the correct financial documentation. This improves the accuracy and clarity of billing information for customers.
Original PR description
When accessing to a bill via the portal, we display a proforma vendor bill, same when we download from the portal, it should not be the case Steps: - Create and confirm a vendor bill - Via the menu action, click on "Share" and copy the link - Open the link -> a proforma vendor bill is displayed - Download the bill -> we get a proforma vendor bill Fix: Allow proforma only for invoices/credit notes opw-5882732
This update fixes a restriction in the Zengin file import process, allowing a wider range of characters to be used. Previously, only specific Japanese characters were permitted, leading to import failures. Now, standard ASCII characters like hyphens and alphanumeric text are supported, ensuring all valid Zengin files can be imported correctly.
Original PR description
Before this commit, the Zengin file import validation was permitting only digits, spaces, and half-width Katakana characters. This limitation caused valid files to fail validation if they contained standard ASCII characters, such as the standard hyphen (which differs from the Katakana prolonged sound mark) or alphanumeric text. This commit updates the validation regex to support the full range of characters allowed by the Zengin specification. The allowed character set has been expanded to include: - Uppercase alphanumeric characters (A-Z, 0-9) - Standard symbols (e.g., -, ., /, (, ), etc.) Ref: https://bqa.smbc.co.jp/faq/show/2473?site_domain=web21lite task-5928087
This update fixes an issue where the Accounts Coverage Report incorrectly flagged deprecated accounts as missing. The change removes a filter that excluded inactive accounts, ensuring the report accurately reflects the company's financial data. This improves the report's reliability and accuracy.
Original PR description
Purpose: Accounts Coverage Report considers only active accounts and deprecated accounts are excluded(which should be included).
Steps to reproduce:-
- Switch to company with Belgian COA.
- Open form view of P&L report and click on Accounts Coverage Report.
- Coverage report raises error message that account 667 is reported but does not exist in COA.
- Create an expense account with code 667000 arbitrarily.
- Coverage report does not raises above error.
- Now deprecate 667000 account.
- Coverage report again raises error that account 667 is reported but does not exist in COA.
Solution: remove `('deprecated', '=', False)` from domain.
task- 5906024
Forward-Port-Of: odoo/enterprise#107085This update resolves an issue where CFDI invoices were generating incorrect report data, specifically displaying '99 - False' instead of the expected '99 - Por definir'. The fix ensures that payment method 99 is accurately reflected in the generated PDF reports, aligning with Mexican tax regulations.
Original PR description
**PROBLEM** PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'. **STEP TO REPRODUCE** 1. Create an invoice with the mx company. 2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice). 3. Send and generate the invoice using cfdi. opw-5927655