Thursday, February 19, 2026
20 changes · 18.0
Resolved issues and error corrections
This fix addresses an error that occurred when creating invoices with negative tax factors. The issue stemmed from a filtering process that resulted in an empty list, causing a data error. We've reverted the recent changes to ensure invoices with negative tax factors can be created without interruption.
Original PR description
Steps to reproduce: - Install `account` module - Taxes > open any existing tax > Set `factor_percent(%)` of repartition lines to negative(eg:…
Steps to reproduce: - Install `account` module - Taxes > open any existing tax > Set `factor_percent(%)` of repartition lines to negative(eg: [Image](https://www.awesomescreenshot.com/image/58851592?key=ce0017bb467a583ad020f33d21d4d8ba)) - Create a Invoice and add tax in move line and save Traceback: `IndexError: list index out of range` We are getting `factors` as empty because `target_factors` from `_add_accounting_data_to_base_line_tax_details` is empty. This happens because, in `tax_reps`, we are filtering repartition lines with a `factor` greater than `0`. However, when the `factor` is less than `0`, `tax_reps` becomes empty, which leads to the error. We are reverting this PR: https://github.com/odoo/odoo/pull/234334 because it prevents the validation error from being raised when there is a negative value in the repartition lines. [factors]: https://github.com/odoo/odoo/blob/de056cc784a3bbe2575fd3c9e81ca62e73c362d4/addons/account/models/account_tax.py#L1641 [tax_reps]: https://github.com/odoo/odoo/blob/de056cc784a3bbe2575fd3c9e81ca62e73c362d4/addons/account/models/account_tax.py#L2429-L2431 sentry-7102210210
This update corrects a default VAT rate issue for Odoo installations using the l10n_ee module. Estonia's VAT rate increased to 24% on July 1, 2025, and this change ensures all new Odoo setups and databases automatically use the correct 24% rate for sales and purchases. This update maintains accurate financial reporting for Estonian businesses.
Original PR description
Issue: Estonia increased its standard VAT rate from 22% to 24% effective July 1, 2025. Existing Odoo installations and new databases created with older templates still default to the outdated 22% rate for sales and purchases. Steps to Reproduce: 1. Install l10n_ee on a fresh database. 2. Go to Accounting > Configuration > Settings. 3. Observe that the default Sales and Purchase taxes are set to 22%. 4. Create a new product; observe it automatically assigns the 22% tax. Solution: - Updated account.tax-ee.csv to set active=False for 22% tax templates and ensure 24% templates are active. - Modified template_ee.py to update account_sale_tax_id and account_purchase_tax_id to point to the new 24% tax IDs. - Updated EU_TAX_MAP in l10n_eu_oss to reflect the 24% destination rate for Estonia across all EU member states. backport of: https://github.com/odoo/odoo/commit/55e3853313969918005757203fc63ee1bd0a3b43 opw-5407921
This update resolves a technical issue where `Image` and `Binary` objects were incorrectly linked. The fix ensures these object types maintain distinct type values, preventing potential data inconsistencies. This improves the stability and reliability of Odoo's file management system.
Original PR description
This fixes an oversight of 4840a6639deb171c28ae14b0269d420aa1503860 that `Image` and `Binary` objects have the same `self.type` value and thus an `Image` can relate to a `Binary`, after all. Forward-Port-Of: odoo/odoo#249260
This update resolves an issue where DHL shipping rate calculations failed when requested for dates outside of DHL's business hours. Adding a 'next business day' flag ensures rates are accurately calculated, preventing errors and ensuring reliable shipping options for customers. This addresses a previous error reported as opw-5393684.
Original PR description
Before this commit, there was an issue when trying to get the rates for DHL shipping late in the day. The issue happened because `plannedShippingDate` fell outside of the working hours. This commit adds the nextBusinessDay flag for the rating request to avoid the error. Error: ``` Product not found 996: The requested product(s) not available for the requested pickup date. Process ID associated for this transaction') ``` opw-5393684 Forward-Port-Of: odoo/enterprise#107153
This update resolves an issue preventing custom address fields from being added to event registration forms. By adding a type check, the system now allows for greater flexibility in custom module overrides, ensuring event registration forms can accommodate a wider range of data inputs. This improves the extensibility of the website event module.
Original PR description
Before the addition of identification questions like "name", "email", and "phone" in the commit [1] as event questions instead of having them static, we could add custom data, such as fields for the address, with static inputs in the form. After that addition, it's no longer possible because the registration gives us the following error when trying to convert data that isn't a M2o ID or an Integer value:
invalid literal for int() with base 10
By adding the check for the field's type, we can still add custom fields with static fields in the template, as an alternative, given that there's no question type for other fields.
[1]: https://github.com/odoo/odoo/commit/6b8daa880c
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prA recent update caused a crash when users attempted to undo a duplicated list within the spreadsheet feature. This fix ensures that the undo function correctly handles list duplication, preventing unexpected errors and improving the user experience. This resolves a bug that impacted list management within the spreadsheet.
Original PR description
How to reproduce: - insert an odoo list in a spreadsheet - duplicate the list from the sidepanel - undo with Ctrl+z -> crash The command "DUPLICATE_ODOO_LIST" was not supported in the inverseCommand registry. Task-5943688 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 resolves an issue where creating multiple email templates using favorites could lead to errors due to excessive nested HTML elements. The fix prevents unnecessary wrapping of templates, ensuring a smoother and more reliable email creation experience. This improvement enhances the stability of the Email Marketing app.
Original PR description
**Steps to reproduce:** - Go to Email Marketing app - Create a new mailing - Click on empty mail body and add only a Heading block - Set a subject, save it and click `Add to Templates` (favorites) - Create another mailing which use the first one as its template - Repeat the operation multiple times - Error will be raised at some point due to the depth of the template html **Issue:** Unnecessarily nested `div` are created when using favorites to create new `mailing.mailing` records, if those favorites are themselves based on other favorites etc., it later can lead to a recursion error when rendering the template. **Fix:** Check if the template comes from the favorites to avoid reapplying the wrappers on it. This seems to be solved in 19.0 with the refactoring (https://github.com/odoo/odoo/commit/354b8f60dbabcfac690d90bf657592e1347e4f86) opw-5275187
This update corrects a rounding issue in the stock barcode scanning process, specifically when handling delivery orders. Previously, quantities were being rounded to a less precise value, leading to discrepancies in stock levels. This fix ensures accurate stock updates during barcode scanning, improving inventory management.
Original PR description
To reproduce the issue: - Create a stock quantity of product1 for example of 275.84 kg in PACK1 - Create a delivery order of 3.6 kg - Go to the delivery order on stock barcode - Scan PACK1 - The new line is created as 272.2399999999
This update addresses a technical issue preventing Virtual IoT boxes from downloading handlers correctly. The change restores a secure process by explicitly verifying SSL certificates, ensuring that IoT handler downloads function reliably. This resolves a previous security oversight related to Python's urllib3 library on Windows.
Original PR description
In PR #233423, we rightfully removed `cert_reqs='CERT_NONE'` to enforce secure certificate validation during IoT handler downloads. However, this exposed a blind spot in Python's `urllib3` library on Windows. Because `urllib3` defaults to the host's underlying certificate list (which is limited on Windows) instead of the installed `certifi` package, Virtual IoT boxes get the following error during handler downloads: `certificate verify failed: unable to get local issuer certificate` This commit restores the broken flow while maintaining security by explicitly passing `certifi.where()` to the `urllib3.PoolManager` via the `ca_certs` parameter. opw-5902549 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249213
This update corrects a discrepancy in payslip calculations for the private car daily allowance. The daily amount is now rounded to two decimal places, ensuring it precisely matches the 'Quantity × Amount' displayed on payslips. This improves the accuracy and clarity of employee compensation information.
Original PR description
Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips. References task-5917569 Forward-Port-Of: odoo/enterprise#106753
This update resolves an issue where test runs were repeatedly generating unnecessary assets, slowing down the testing process. By adding the 'web_studio.studio_assets' bundle to the pregeneration list, tests now run more efficiently and reliably. This improves overall development speed.
Original PR description
During tests runs, lazy loaded assets are generated on the fly, and eventually multiple hundred of times (i.e. +/- 150 times on runbot). This commit adds the `web_studio.studio_assets` bundle to the pregeneration list to avoid regenerating during tests runs. Forward-Port-Of: odoo/enterprise#107147
This update resolves an issue where tests interfering with model registration caused lookup failures and incorrect data retrieval. The change ensures more reliable model identification by using string lookups instead of class names, preventing potential mismatches and improving system stability. This enhances the overall robustness of the Odoo platform.
Original PR description
Followup to #247151 after community report that if a test swizzles the model in the registry, looking models up by class leads to a lookup failure and a fallback to the default attributes set, and an almost certain mismatch as a result.
This update enhances the speed and accuracy of searching within the Web Studio module. The change refines how search indexes are created, now prioritizing indexing by model name instead of class. This results in faster and more relevant search results for users.
This update corrects an issue where pick-up point names and addresses were incorrectly capitalized, particularly in Dutch. The fix ensures all pick-up point names and weekday labels are consistently capitalized regardless of the selected language, improving the user experience and data presentation.
Original PR description
Issue: --- In pick-up point list, the case formatting should be: 1- Pick-up point's `name`, `street` and `city` should not be auto-capitalized. 2- Weekdays should must be always capitalized regardless of language. Steps to reproduce: --- 1- Create a second Company named `store`. 2- Create a wh for the created company and add the wh to click-and-collect pick-up points. (There should be more than 1 pick-up points) 3- In the website, add Dutch lang. 4- In website, open a product and, open the `Click and Collect`. Outcome: --- Name is capitalized to `Store` and the days are not capitalized if you switch to dutch lang. Cause: --- Due to CLDR, luxon doesn't capitalize weekdays in some languages. opw-5941830
This update fixes a bug in the Colombian Daily Journal report that prevented users from searching for transactions. The issue was caused by missing data in the report's search field, which is now corrected to include move names, partners, accounts, and labels. This ensures accurate and efficient searching within the Daily Journal.
Original PR description
Steps to reproduce: 1. Open the Colombian Daily Journal (Libro Diario). 2. Type a move name or partner in the search bar. 3. Observe that no results are returned. Cause: Report lines were generated with an empty 'name' attribute. The accounting report framework uses this field for client-side filtering. Empty names make the search bar non-functional. Solution: Populate the 'name' field with move, partner, account, and label data. This enables the frontend search bar to match against these strings. opw-5495558
This update resolves a technical issue that caused tracebacks when opening barcode rule forms within the Stock module. The fix removes a dependency on a parent record, ensuring the form loads correctly and preventing errors. This improves stability and user experience.
Original PR description
Issue before this commit: ========================= When opening a Barcode Rule form view, a traceback was raised due to the following python expression: bool(parent.is_gs1_nomenclature or type ==…
Issue before this commit: ========================= When opening a Barcode Rule form view, a traceback was raised due to the following python expression: bool(parent.is_gs1_nomenclature or type == 'alias') Steps to Reproduce: ========================= - Install the stock module. - Go to Configuration → Barcode Nomenclatures in the Stock app. - Open any Barcode Nomenclature form. - Go to the Rules tab and open a rule (pop-up form view). - Click on the Expand button. - A traceback is raised. Cause of the issue: ========================= The form view tries to evaluate `parent.is_gs1_nomenclature`, but the `parent` record is not defined when the rule form view is opened directly (via expand), leading to a traceback. This happens because the form view is not defined as a child of any parent view, so no parent context is available, which leads to a traceback. With This Commit: ========================= Removed the usage of `parent.is_gs1_nomenclature` and use `is_gs1_nomenclature` directly instead. The `is_gs1_nomenclature` field on `barcode.rule` is already a related field to `barcode.nomenclature`, so it can be safely used without relying on the parent. opw-5949083
This update prevents unnecessary OCR processing on split expenses, which was causing unexpected charges for users with automatic digitization enabled. The fix addresses a bug previously resolved in later versions of Odoo, and ensures efficient use of IAP credits. This change minimizes potential user costs.
Original PR description
OCR should only be performed on the original document. Enabling it on splits leads to redundant OCR requests and unnecessary IAP credit consumption. This is particularly important when automatic digitization is enabled, as it triggers a paid request for every split generated, leading to unexpected costs for the user. The same bug was fixed in version 19.0 and up (commit 0688575), but it couldn't be backported as the `split_expense_origin_id` field doesn't exist in version 18.0. opw-[5930791](https://www.odoo.com/odoo/project/2068/tasks/5930791)
This update resolves a technical issue preventing accurate scale readings for certified weighing operations. The fix addresses a problem where the system was incorrectly interpreting scale data, leading to inaccurate results. This ensures correct data capture for scale certifications, improving the reliability of the IoT integration.
Original PR description
This PR fixes the lack of compatibility with the new event manager code sending result instead of value, fixing the weighing stuck at 0 in some situations
This update addresses a technical issue related to the transmission of Swiss payroll data (LPP). Specifically, it ensures the 13th month salary is correctly included in the base calculation for reporting purposes, aligning with Swiss tax regulations. This correction improves the accuracy of financial reporting and compliance.
Original PR description
Forward-Port-Of: odoo/enterprise#107908
Features or functions removed from Odoo
This update simplifies the Spanish accounting module by removing a complex distinction between domestic, intra-EU, and extra-EU sales. The original setup was based on outdated regulations and isn't reflected in current reporting. This change streamlines the accounting process and aligns with current Spanish tax requirements.
Original PR description
I can’t find any explanation for why the sales acounts were originally split into domestic sales (Spain), intra-EU sales, and extra-EU sales. It doesn’t look like there is any report that considers this separation anyway. Reference link: https://www.boe.es/diario_boe/txt.php?id=BOE-A-2013-3781 CLA signed in https://github.com/odoo/odoo/pull/239246 TT59545 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr