Odoo Changelog — 2026-05-16

Saturday, May 16, 2026

6 changes · saas-19.1

Bug Fixes(6)

Resolved issues and error corrections

[FIX] l10n_it_edi: bank account import missing

Coresaas-19.1l10n_it_edi

This update resolves an issue where Italian EDI bank account imports weren't automatically creating new bank accounts. The fix ensures that bank account records are now created and properly assigned to the corresponding customer, improving the accuracy of financial data. This change was driven by a test case related to simplified invoices.

Original PR description

The Italian EDI import didn't create new bank account by itself. IBAN info was just logged in the chatter, leaving it up for the accountant to create the bank account record.

The bank account should be created and assigned to the corresponding commercial partner and set to not trusted yet.

Enterprise PR: odoo/enterprise#112794

Task [link](https://www.odoo.com/odoo/project.task/6046189)
task-6046189

Forward-Port-Of: odoo/odoo#264382
Forward-Port-Of: odoo/odoo#254505

#accounting#Italy#EDI

[FIX] l10n_it_reports: Fix test for partner and bank account import

PR #117501

Enterprisesaas-19.1l10n_it_reports

This update resolves a test failure related to importing partner and bank account data for Italian reporting. The team restored a specific data state within the test file, ensuring the tests now pass correctly. This prevents disruptions to the Italian reporting functionality.

Original PR description

The related PR brings a data change in a test file that is used here. We bring back the state of that data in the test class, so that the tests don't fail anymore.

Community PR: odoo/odoo#254505

Task [link](https://www.odoo.com/odoo/project.task/6046189)
task-6046189

Forward-Port-Of: odoo/enterprise#117275
Forward-Port-Of: odoo/enterprise#112794

#reporting#italian#test

[FIX] hr_holidays: match correct allocation stats for duplicated leave types

PR #264744

Coresaas-19.1hr_holidaysMEDIUM

This update resolves an issue where duplicated leave types (with the same name) were causing incorrect allocation statistics to be displayed in the Time Off request wizard. The fix ensures that each leave type is uniquely identified by its ID, preventing data conflicts and accurate leave calculations.

Original PR description

Steps to reproduce:
---------------------------------------
1. Go to Time Off type which has no Company
2. Allocation Smart button > New
3. Set allocation for some days (e. g, 10 Days) > Approve allocation
4. Now, click on Employee > Time Off smart button
5. On the Dashboard, you can see allocated leaves
6. Click on any day to create a Time Off Request

Observation:
---------------------------------------
The allocated Time Off Type is not available in the request wizard, even though allocation exists.

Issue:
---------------------------------------
When natively computing allocation statistics for the UI, the `_compute_leaves` loops through a pre-fetched `data_days` structure and incorrectly extracts the calculation metrics by matching the `holiday_status.name` string via a list comprehension lookup index (`item[0]`).
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/hr_holidays/models/hr_leave_type.py#L288-L294

If Time Off Type A and Time Off Type B share the name 'Generic Leave', the list comprehension evaluates sequentially and forcefully maps the dictionary of whichever version structurally sits first in the memory sequence directly onto both overlapping identifiers simultaneously!

Solution:
---------------------------------------
Directly match records using their unique ID.
This ensures that each database record always retrieves its own correct data, preventing any mix-up or accidental sharing of values between records that may have the same name.

opw-6105759

Forward-Port-Of: odoo/odoo#264104
Forward-Port-Of: odoo/odoo#261680

#leave#allocation#time off

[FIX] orm: optimize tautology before calling search

PR #264812

Coresaas-19.1orm

This update optimizes how Odoo handles boolean searches, specifically when searching for fields that can be True or False. By moving the optimization step earlier in the process, the system now correctly handles a wider range of search implementations, leading to faster and more reliable search results. This change improves overall system performance and stability.

Original PR description

When optizing `('searchable_bool_field', 'in', [True, False])`, the optimization for the tautology is called after the search method. We should do it before as this case may not be handled by implementations which always expect `'in'/'not in', [True]`.


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#264636

#performance#search#optimization

[REV] stock: ensure packaging unit and qty are shown for validated transfers

PR #264813

Coresaas-19.1stock

This update ensures that delivery slips now accurately display the packaging unit and quantity used for validated stock transfers. This change was reverted to align with a previous update and addresses a dependency on the stock_barcode module, which wasn't initially present. This improves the clarity and accuracy of delivery reports.

Original PR description

This reverts commit efab5c52569d64e6d73cacf7611a40b025df52fb.

`packaging_uom_id` only exists on `stock.move.line` once the stock_barcode module is installed.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#264746

#stock#reporting#delivery

[FIX] im_livechat,web: no double rendering of overlay container

PR #264783

Coresaas-19.1webim_livechatportal

This update corrects a visual glitch where overlays (like Dialogs) sometimes appeared twice when initially displayed. The change improves the stability and user experience by preventing unnecessary re-renders of these overlays, ensuring a smoother display.

Original PR description

Before this commit, sometimes an overlay such as Dialog could flicker and render twice on mount. This comes from implementation details for detecting whether the overlay comes from shadow DOM or…

Before this commit, sometimes an overlay such as Dialog could flicker and render twice on mount.

This comes from implementation details for detecting whether the overlay comes from shadow DOM or website, to determine which overlay container should decide to display the overlay [1]. The code relies on presence of the root id in the DOM and overlay container was relying on presence of `ref.el` to get the root id from DOM. This was motivated by `isVisible(overlay)` whose computation was also relying on the ref [2] but this has the drawback that `ref.el` was sometimes not yet available immediately on 1st rendering. Solution of [1] was to re-renderer whenever `ref.el` is set, but another solution that prevents a re-render is to have the root id in the `env`.

This commit changes the solution of [1] by instead `rootId` in the `env`. The new solution has the benefit to not require a re-render of the overlay container, which prevents undesirable flickers that may happen on mounting an overlay for the 1st time.

[1]: odoo#169264
[2]: odoo#154349

Forward-Port-Of: odoo/odoo#263860

#UI#stability#overlay

The Italian EDI import didn't create new bank account by itself. IBAN info was just logged in the chatter, leaving it up for the accountant to create the bank account record. The bank account should be created and assigned to the corresponding commercial partner and set to not trusted yet. Enterprise PR: odoo/enterprise#112794 Task [link](https://www.odoo.com/odoo/project.task/6046189) task-6046189 Forward-Port-Of: odoo/odoo#264382 Forward-Port-Of: odoo/odoo#254505

The related PR brings a data change in a test file that is used here. We bring back the state of that data in the test class, so that the tests don't fail anymore. Community PR: odoo/odoo#254505 Task [link](https://www.odoo.com/odoo/project.task/6046189) task-6046189 Forward-Port-Of: odoo/enterprise#117275 Forward-Port-Of: odoo/enterprise#112794

Pre-requisite: --------------------------------------- 1. Install the Time Off module 2. Create a new company (e.g, Test Company) 3. Create New Timeoff Type: * Ensure a default company is set (e.g, YourCompany) 4. Duplicate the created Time off type: * Remove (Copy) from the name so both records share the same name * Clear the Company field on the duplicated record Steps to reproduce: --------------------------------------- 1. Go to Time Off type which has no Company 2. Allocation Smart button > New 3. Set allocation for some days (e. g, 10 Days) > Approve allocation 4. Now, click on Employee > Time Off smart button 5. On the Dashboard, you can see allocated leaves 6. Click on any day to create a Time Off Request Observation: --------------------------------------- The allocated Time Off Type is not available in the request wizard, even though allocation exists. Issue: --------------------------------------- When natively computing allocation statistics for the UI, the `_compute_leaves` loops through a pre-fetched `data_days` structure and incorrectly extracts the calculation metrics by matching the `holiday_status.name` string via a list comprehension lookup index (`item[0]`). https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/hr_holidays/models/hr_leave_type.py#L288-L294 If Time Off Type A and Time Off Type B share the name 'Generic Leave', the list comprehension evaluates sequentially and forcefully maps the dictionary of whichever version structurally sits first in the memory sequence directly onto both overlapping identifiers simultaneously! Solution: --------------------------------------- Directly match records using their unique ID. This ensures that each database record always retrieves its own correct data, preventing any mix-up or accidental sharing of values between records that may have the same name. opw-6105759 Forward-Port-Of: odoo/odoo#264104 Forward-Port-Of: odoo/odoo#261680

When optizing `('searchable_bool_field', 'in', [True, False])`, the optimization for the tautology is called after the search method. We should do it before as this case may not be handled by implementations which always expect `'in'/'not in', [True]`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264636

This reverts commit efab5c52569d64e6d73cacf7611a40b025df52fb. `packaging_uom_id` only exists on `stock.move.line` once the stock_barcode module is installed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264746

Before this commit, sometimes an overlay such as Dialog could flicker and render twice on mount. This comes from implementation details for detecting whether the overlay comes from shadow DOM or website, to determine which overlay container should decide to display the overlay [1]. The code relies on presence of the root id in the DOM and overlay container was relying on presence of `ref.el` to get the root id from DOM. This was motivated by `isVisible(overlay)` whose computation was also relying on the ref [2] but this has the drawback that `ref.el` was sometimes not yet available immediately on 1st rendering. Solution of [1] was to re-renderer whenever `ref.el` is set, but another solution that prevents a re-render is to have the root id in the `env`. This commit changes the solution of [1] by instead `rootId` in the `env`. The new solution has the benefit to not require a re-render of the overlay container, which prevents undesirable flickers that may happen on mounting an overlay for the 1st time. [1]: odoo#169264 [2]: odoo#154349 Forward-Port-Of: odoo/odoo#263860