Odoo Changelog — 2025-06-24

Tuesday, June 24, 2025

2 changes · 18.0

Improvements(2)

Enhancements to existing features

[IMP] account: check for duplicate when creating a bank account

PR #198127

Core18.0accountMedium

When creating a bank account, users now see a non-blocking warning if the same account is already linked to another partner. This helps prevent duplicate bank account records while still allowing users to continue when appropriate.

Original PR description

If a bank account is already linked to a partner, display a non-blocking warning on the bank account creation form, containing a link to the other partner.

task-4431041

#bank accounts#duplicate detection#partners

[PERF] planning: import public holidays

PR #88351

Enterprise18.0planning_holidaysMedium

Importing public holidays in Planning is now much faster on databases with many scheduled shifts. The change lets Odoo process affected planning hours more efficiently in batches, reducing a reported import from about 40 minutes to 4 minutes.

Original PR description

The current code of `_recompute_shifts_in_leave_periods` explicitely calls the compute method `_compute_allocated_hours` of planning.slot to recompute the allocated hours according to modifications done to the public holidays. Calling the method directly like that is far from ideal as we are missing proper batching, fields protection, etc.. that the ORM usually does for computed fields.

This commit replaces the explicit call by an `add_to_compute`. This essentially marks the field as "to be recomputed". This recomputation then happens at the next flush_model/recompute_model call and can applies the proper ORM optimizations of batching by `PREFETCH_MAX` size, protecting fields to avoid triggering loops of recomputations. This speeds up the import of new Public Holidays in an already populated database.

#### speedup

In a customer database with 50K planning.slots, 1300 of which needs to recompute their allocated_hours, the import timing Before PR vs After PR is the following:
- 40 min -> 4 min

opw-4782452

The current code of `_recompute_shifts_in_leave_periods` explicitely calls the compute method `_compute_allocated_hours` of planning.slot to recompute the allocated hours according to modifications done to the public holidays. Calling the method directly like that is far from ideal as we are missing proper batching, fields protection, etc.. that the ORM usually does for computed fields. This commit replaces the explicit call by an `add_to_compute`. This essentially marks the field as "to be recomputed". This recomputation then happens at the next flush_model/recompute_model call and can applies the proper ORM optimizations of batching by `PREFETCH_MAX` size, protecting fields to avoid triggering loops of recomputations. This speeds up the import of new Public Holidays in an already populated database. #### speedup In a customer database with 50K planning.slots, 1300 of which needs to recompute their allocated_hours, the import timing Before PR vs After PR is the following: - 40 min -> 4 min opw-4782452