Thursday, February 12, 2026
27 changes · 19.0
New functionality added to Odoo
This update ensures the account search dialog correctly displays in dark mode. Previously, dark mode wasn't fully supported, leading to inconsistent visuals. This change improves the user experience and visual consistency across Odoo Enterprise.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/e3dec031033eeefb2b2271be6b0b6fbda3cf5bf0 the dark mode was not rightly supported. task-5932352
Enhancements to existing features
This update changes wording around combo product choices so customers and staff no longer see them described as “free.” The new labels make it clearer that these items are included in the overall combo price, reducing confusion in the backend and point of sale.
Original PR description
Description of the issue/feature this PR addresses: combo choice products are not free products. They are included in the combo product price. Therefore it creates misunderstanding for our users Current behavior before PR: Desired behavior after PR is merged: Change the "free" string into "item" in the backend and into "included" in pos frontend to align with the display in self --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fixes a visual issue in Kanban views where holding ALT to show card selection could make ribbons appear in the wrong place. Users can now use multi-selection cues without disrupting the layout of cards that include ribbons.
Original PR description
The CSS rules of `.o_record_selection_available` are used to add a selection overlay on kanban cards. These rules relied on `filter: brightness()` to slightly dim all child elements when pressing `ALT`. However, using filter creates a new stacking context. As a result, when a ribbon is present, it no longer sticks to the card border and becomes misplaced. This commit updates the rules to avoid that behavior and keep the ribbon correctly positioned. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248164 Forward-Port-Of: odoo/odoo#247985
This fixes an intermittent automated test failure around image handling by waiting for image data conversion to finish explicitly. It helps keep quality checks stable and reduces false alarms during development and release validation.
Original PR description
Encoding the data to base64 can take some times. Before this commit we used this code: ```js await runAllTimers(); await animationFrame(); ``` Now we explicitly wait for the change to happen as awaiting an animation frame can't be enough. runbot-error-237568 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248166
The Saudi e-invoicing onboarding flow now handles companies that do not have a street address filled in. This prevents an error when entering the ZATCA OTP, allowing the journal onboarding request to proceed more reliably.
Original PR description
This error occurs when attempting to set the "OTP" received from "ZATCA". Steps to reproduce: - Install `l10n_sa_edi` module > Switch to `SA Company` - Go to `SA Company` and remove `Street` - Journals > Open journal with type 'Sale' > ZATCA > Onboard Journal > Enter any OTP > Request Traceback: `TypeError- value argument must be a str` At [1], the error occurs because the company has an empty street field, causing the value argument to be a `boolean` instead of the expected `string`. [1]- https://github.com/odoo/odoo/blob/40a0b44231fd9a725ccf3667c4992e691e24cde7/addons/l10n_sa_edi/models/certificate.py#L71 sentry-7185302332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243525
Kiosk preparation tickets now use the same layout style as regular POS tickets. This makes printed tickets easier to read and shows product names and attributes in a clearer, more consistent format for kitchen or preparation staff.
Original PR description
Before this commit, preparation tickets printed from kiosk had a different structure from those printed from the POS. Two differences were spotted: 1. Font size was smaller than ticket printed from the pos 2. The name of the product displayed was the full product name instead of the basic one with attributes under the product name. So, to fix that I basically used the same template structure from the point_of_sale module and adapted data to fit with. task : 5506329 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change adds automated checks to ensure loyalty points are not applied more than once when a point-of-sale order is saved as a draft or later cancelled. It helps protect customer reward balances from accidental inflation and improves confidence in loyalty program accuracy.
Original PR description
Step to reproduce: - have a trusted pos and a loyalty program which gives points per $ spent - start pos and select order and a partner (he should already have some LPs) - notice the loyalty points…
Step to reproduce:
- have a trusted pos and a loyalty program which gives points per $ spent
- start pos and select order and a partner (he should already have some LPs)
- notice the loyalty points assgined
- save the order, you are redirected to new order
- switch back to original order
Observation:
- Notice, the loyalty points are reassigned for example :
- if initially partner's LP = 50, product added is 100$ , LP = 50+100 = 150
- After saving, LP becomes 150 + 100 = 250
Cause:
- LP's are processed after every `sync_from_ui` call from `_postProcessLoyalty` which updates the customer's lp, even before the order is fullfilled or when order is still in `draft` state
Fix:
- Issue is fixed in https://github.com/odoo/odoo/commit/a4b37ec474656c7af23d0134251d589e9a6a61ca
- This commit adds related test for the fix
opw-5609964
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#248077
Forward-Port-Of: odoo/odoo#245400The website editor snippet dialog now shows carousel previews at the intended height. This prevents oversized previews, making it easier for users to browse and choose carousel snippets while building pages.
Original PR description
Steps to reproduce: - Open the website editor. - Open the snippet dialog. - Look at a carousel snippet preview. => The preview height is too tall. Before this commit, the dialog loads CSS after JS, so "computeMaxHeight" ran on an unstyled DOM and missed the "fit-content" height for the carousel. After this commit, the preview forces "fit-content" in JS so the height matches the final CSS layout. task-5156137 **To see/test the bug, the change made in https://github.com/odoo/odoo/pull/244295 must be present** Forward-Port-Of: odoo/odoo#244662
The rental schedule now includes all product groups when the number of products exactly matches the configured display limit. This prevents some products from disappearing from grouped schedule views even though the limit has not been exceeded.
Original PR description
Versions -------- - 19.0+ Steps ----- 1. Create exactly 19 rental products. 2. Go to the rental schedule, and group by products. 3. Observe that all 19 product are used as groups. 4. Create one more product. Total: 20. 5. Go to the rental schedule, and group by products. Issue ----- Only the products with actual order line linked to them are used as groups, even if there isn't more products than the hard limit set on the gantt view (`sale_renting.sale_order_line_gantt_schedule`). Cause ----- In d5a6e97abab04282c7a69093cd790b539a958241, the expanded groups are taken into account only if `len(expand_groups) < limit`. However, this should be a less than _or equal_ condition. https://github.com/odoo/odoo/blob/d5a6e97abab04282c7a69093cd790b539a958241/addons/web/models/models.py#L345-L349 Solution -------- Use `<=` as the condition. opw-5887837
This fix makes an automated point of sale tax test wait for invoicing to be fully selected before completing payment. It reduces false test failures in localized accounting scenarios, helping keep releases stable without changing user-facing behavior.
Original PR description
The `test_point_of_sale_custom_tax_with_extra_product_field` test does a `PaymentScreen.clickInvoiceButton()` and then directly after that a `PaymentScreen.clickValidate()`. In l10n scenarios, the logic behind triggering the `toInvoice` field can take longer. This would cause the validation to execute before the `toggleIsToInvoice` finishes executing and then it would throw an error that the order was already finalized. This PR ads an extra wait on the `Invoice` button to make sure that the toggle is executed properly before finalizing the order. Runbot Error: [233024](https://runbot.odoo.com/odoo/runbot.build.error/233024) Task: [5897371](https://www.odoo.com/odoo/project/1737/tasks/5897371) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248191
This fix prevents Odoo module updates from failing when outdated or inconsistent field records are encountered. It adds a safeguard so only compatible field types are processed for deletion rules, improving update reliability without changing normal user workflows.
Original PR description
Description of the issue/feature this PR addresses: Fix AttributeError that occurs during module updates when processing selection field deletions. Current behavior before PR: When updating modules, an `AttributeError` occurs when trying to access the `ondelete` attribute on fields that are not Selection fields: AttributeError: 'Char' object has no attribute 'ondelete' Desired behavior after PR is merged: Add validation to check if the field type is 'selection' or 'reference' before attempting to access field.ondelete as a dictionary. Skip processing for incompatible field types to prevent AttributeError. @moduon MT-13588 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247971
This update fixes several reliability issues in Odoo's internal profiling tools, including shutdown timing problems and memory collection errors. It helps developers diagnose performance issues more consistently without profiler crashes or delays.
Original PR description
Multiple fixes for the Profiler. Issues: - Python throws cannot join current thread when using the entry count with memory and traces async profilers. - The periodic profilers were waiting the full amount of the sleep before ending. - When using the entry_count, the memory profiler was throwing a non serializable object error - Sometimes the memory collector throws an error that the tracemalloc needs to be started so that it collects. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The product configurator now keeps its Add to Cart button text on one line and adjusts when the label appears on smaller screens. This prevents awkward wrapping and makes the shopping experience cleaner on mobile and tablet layouts.
Original PR description
This commit fixes some text wrapping issues for the buttons inside the product configurator: - Change "Add to Cart" text visibility from d-md-inline to d-lg-inline for better mobile layout and prevent text wrapping - Add text-nowrap class to configurator's footer primary button to prevent text wrapping task-5896776 | Before | After | |--------|--------| | <img width="1029" height="781" alt="image" src="https://github.com/user-attachments/assets/fa9106df-c8ee-4ade-a8ce-466549b8e816" /> | <img width="1029" height="781" alt="image" src="https://github.com/user-attachments/assets/70de2a6a-b6d8-43da-bbdb-97e1b921078b" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes popover timing consistent during automated tests, preventing rare timing-related failures. It improves confidence in test results without changing day-to-day user behavior.
Original PR description
Because the popover had his animation enabled in tests, it could in very rare occasion end too fast and call it's finished callback, triggering extra repositionning (and thus extra expect.steps). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247341 Forward-Port-Of: odoo/odoo#244491
This update fixes an issue where tasks auto-planned with specific start dates were incorrectly limited to shorter durations. The system was re-using previously scheduled intervals, preventing tasks from extending into the following month. The fix ensures tasks accurately calculate and schedule the required hours, avoiding scheduling errors.
Original PR description
Steps to Reproduce: 1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result,…
Steps to Reproduce: 1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result, the allocated period is shorter than the required hours. Source: When selecting 25/11/2025 as the start date, the system tries to schedule the task within the remaining days of November (25–28). However, these four days are not enough to cover 40 hours. The system then searches for available intervals in the next month. But the intervals from November are still kept in the list, so when the algorithm iterates again, it reuses the previously consumed intervals (25 and 26). This causes the scheduler to allocate the remaining hours to those same days, leading to an incorrect result where the task spans only 25–26 November, instead of continuing from 1 December. Solution: Remove already-used intervals before recomputing the schedule. opw-5364327 Forward-Port-Of: odoo/enterprise#106160 Forward-Port-Of: odoo/enterprise#101262
This update resolves a runbot test failure caused by the automatic installation of the SEPA module during chart of account loading. The fix disables automatic module installation during testing to prevent database modifications, ensuring consistent and reliable test results.
Original PR description
**PROBLEM** https://github.com/odoo/enterprise/pull/106033 PR above fixes the auto install of the sepa module when loading a chart of account of some country. However, installing modules during tests is not allowed (it commits real transaction to the db). It didn't occur during the "daily" runbot because they start the tests with all modules installed (sepa module included). **REPRO STEPS** 1. On a db without the sepa module installed, run the test function .test_bank_account_code_prefix (in account module). 2. The test will fail because it load a chart of account and then try to install the sepa module. **FIX** Deactivate the auto install when running tests. runbot-238921
A test for the Shiprocket delivery module failed due to a default pricelist being applied, incorrectly overriding tax calculations. This change forces an empty pricelist during testing, ensuring accurate tax calculations and resolving the test failure. This improves the reliability of the Shiprocket delivery module tests.
Original PR description
Issue
-----
`File "/data/build/enterprise/delivery_shiprocket/tests/test_delivery_shiprocket.py", line 317, in test_shiprocket_delivery_with_discounts
self.assertAlmostEqual(sale_order.amount_total, 55)
AssertionError: 32.0 != 55 within 7 places (23.0 difference)
`
Cause
-----
Test fails because a pricelist gets applied by default and overrides the taxes.
-----
Error runbot 232692
Forward-Port-Of: odoo/enterprise#105180This update resolves a technical issue in the l10n_nl_reports module that was causing a TypeError due to incorrect handling of a boolean value within a report generation process. The fix ensures that the system correctly processes this value, preventing errors and ensuring accurate report generation for Dutch users.
Original PR description
The dict returned by ```ec_sales_list_tags_info``` contains a configuration key ```use_taxes_instead_of_tags```(boolean). ```sql (Pdb) ec_sales_list_tags_info {'goods': [221], 'services': [223],…
The dict returned by ```ec_sales_list_tags_info``` contains a configuration key ```use_taxes_instead_of_tags```(boolean).
```sql
(Pdb) ec_sales_list_tags_info
{'goods': [221], 'services': [223], 'triangular': [204], 'use_taxes_instead_of_tags': False}
(Pdb) ec_sales_list_tag_ids = list(chain(*ec_sales_list_tags_info.values()))
TypeError: 'bool' object is not iterable
```
The previous implementation blindly passed all values to `chain()`, causing a TypeError when encountering the boolean value
```sql
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1510, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 199, in new
load_modules(
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 493, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/19.0/odoo/modules/migration.py", line 220, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/src/odoo/19.0/odoo/modules/migration.py", line 257, in exec_script
mod.migrate(cr, installed_version)
File "/tmp/tmpzg7oi478/migrations/account_reports/saas~18.3.1.0/end-account-returns.py", line 341, in migrate
generate_or_refresh_all_returns(company)
File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 232, in _generate_or_refresh_all_returns
self._generate_all_returns(fiscal_country.code, company, domestic_tax_unit)
File "/home/odoo/src/enterprise/19.0/l10n_nl_reports/models/account_return.py", line 22, in _generate_all_returns
ec_sales_list_tag_ids = list(chain(*ec_sales_list_tags_info.values()))
TypeError: 'bool' object is not iterable
```
upg-3871388
opw-5901777This update resolves an issue where customer display URLs weren't consistently being sent to IoT devices when updating records in the IoT device form. The change ensures that the correct URL is transmitted, improving the functionality of the IoT integration. This was a minor bug fix.
Original PR description
This PR fixes the customer display url not being sent to the iot box when updating the corresponding record in iot device form view. By replacing onWillSaveRecord by onRecordSaved we ensure that our method is always called ticket-5782927 Forward-Port-Of: odoo/enterprise#106621 Forward-Port-Of: odoo/enterprise#106331
This update corrects a display issue in the rental schedule Gantt view where product grouping was repeatedly reappearing after removal. The fix removes a conflicting default setting, ensuring the Gantt view groups by product as intended. This improves the user experience when managing rental schedules.
Original PR description
Versions -------- - 19.0+ Steps ----- 1. Install the Rental and Inventory apps. 2. Go to the rental schedule. 3. Observe the gantt view is grouped by product by default. 4. Remove the product groupby…
Versions -------- - 19.0+ Steps ----- 1. Install the Rental and Inventory apps. 2. Go to the rental schedule. 3. Observe the gantt view is grouped by product by default. 4. Remove the product groupby filter. Issue ----- The product groupby filter reappears. Cause ----- The base gantt view defines `default_group` as product. Additionally, the `sale_stock_renting` module overrides the `sale_renting.action_rental_order_schedule` action to add two default groupby filters: `search_default_groupby_product` and `search_default_groupby_reserved_lot`. This creates conflicting defaults: one from the gantt view directly (groupby product) and another from the context (groupby product and reserved lot). Since lots are disabled by default, the lot groupby filter is ignored. When removing the product filter, the framework falls back to `default_group` and reactivates the product groupby filter. Solution -------- Remove the `default_group` parameter from the gantt view. Ensure all actions using the gantt view define their own defaults via context. opw-5887837
This update corrects a technical issue where crucial data was missing from German tax report exports. The change ensures that all required information is now accurately included in the reports, complying with German tax regulations. This fix is important for accurate financial reporting and compliance.
Original PR description
After the change in the german tax report layout, we incorrectly removed some values from the report export. Add missing values back into the report. original commit: https://github.com/odoo/enterprise/pull/97486/changes/0c579c824b1bf2eb643d2314b38d108cf72139c6 opw-5481368
This update resolves an issue preventing users from modifying Purchase Display Invoices (PDIs) when a Point of Sale (PoS) session is active. Now, PDIs can be edited regardless of whether there are active orders, improving workflow flexibility. This change simplifies the process for managing invoices.
Original PR description
Steps to reproduce : 1. Open a POS session 2. Create a pdis with all PoS 3. An error is raised So now, when we creating a new pdis or when there is no ongoing orders in this pdis, we allow to modify it. But if there is ongoing orders, user cannot. task : 5881587
This update fixes a display issue where tax amounts were incorrectly shown as negative in the tax totals widget for credit notes. The fix ensures that tax calculations are accurate, presenting the correct tax amount for ICMS on credit notes. This improves the reliability of financial reporting.
Original PR description
Currently, when computing taxes for a credit note, the system will show the included tax as negative in the tax totals widget Steps to reproduce: - Setup a BR Company - Setup a product requiring tax ICMS included in price - Create a credit note with the product - Compute taxes Issue: In tax totals widget the tax amount will be reported as negative, even if the tax line balance is correct. opw-5866180 Forward-Port-Of: odoo/enterprise#107039 Forward-Port-Of: odoo/enterprise#106579
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 greater flexibility for importing bank statements.
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 Forward-Port-Of: odoo/enterprise#107007
This update resolves a minor issue related to the scale certificate checksum. It reflects a recent fix implemented in the Odoo community project (odoo/odoo#248416), ensuring consistent and accurate checksum calculations. This change maintains the integrity of the certificate data.
Original PR description
This commit simply updates the expected scale checksum after the fix in the community PR odoo/odoo#248416.
This update fixes an issue where the 'Back to Production' button in the product catalog, opened from the shop floor, incorrectly navigated users to the Manufacturing Order form. The button text and redirection logic have been updated to ensure users are correctly returned to the Shop Floor, improving usability and workflow efficiency.
Original PR description
Before this commit: ==================== When opening the product catalog from shop floor, the Back button is labeled “Back to Production” and navigates the users to Manufacturing Order(MO) form view…
Before this commit: ==================== When opening the product catalog from shop floor, the Back button is labeled “Back to Production” and navigates the users to Manufacturing Order(MO) form view instead of returning to Shop Floor. Steps to Reproduce: ==================== 1. Install `mrp_workorder` module. 2. Create a MO → Open it in `ShopFloor` → Open the Product Catalog to add a component to the MO. 3. Click on `Back to Production`. It will redirect to MO form view. Cause of the issue: ==================== The `backToQuotation` method in `ProductCatalogKanbanController` redirects the user back using breadcrumbs, and when no breadcrumbs exist, it falls back to opening the form view. Since the catalog is opened from the Shop Floor without any breadcrumbs, the user is always redirected to the MO form view. After this commit:- ==================== These changes rename the back button to `Back to Shop Floor` and ensure it redirects users to the Shop Floor when the catalog is opened from there. TaskID-5355924
This update simplifies the process for creating expense reports by switching from automated KYC pre-filling to a manual verification step. This change addresses potential errors caused by inconsistent data formats in certain regions, like the Netherlands, and ensures accurate expense reporting.
Original PR description
Context:
When creating a livemode account, the data pre-sent by the database to stripe may cause issues in some localizations. e.g. the Netherland where people are forced to use a zip in the "\d{4} ?[A-Z]{2}" pattern, which they do not alway do
Solution:
Pre-filling KYC was deemed too error-prone and this would be switched to a fully manual KYC
OPW-5899276
Linked (but not depending on) https://github.com/odoo/iap-apps/pull/1431