Odoo Changelog — 2026-04-17

Friday, April 17, 2026

2 changes · 19.0

Improvements(2)

Enhancements to existing features

[IMP] project: redirect portal editors to project sharing view

Core19.0projectMedium

Portal users who have editing rights through Project Sharing are now sent directly to the editable shared project view from task email links. This avoids confusion from landing on a read-only page and helps external collaborators act on tasks faster.

Original PR description

Before this commit, the action link sent in task email notifications to portal users always redirected to the standard, read-only portal view, even if the user had edit rights to the project via Project Sharing.

This commit ensures that:
- If a portal user has access to the task and the project has Project Sharing enabled for them, the action URL redirects directly to the editable project sharing view instead of the static portal page.

task-5221400

#portal#project sharing#email notifications#tasks

[PERF] account,product: optimize memory usage when assigning chart templates

PR #259304

Core19.0accountproductMedium

Assigning a Chart of Accounts or Fiscal Localization now uses far less memory and completes much faster on databases with very large product catalogs. This reduces the risk of setup failures and improves reliability for customers with millions of products.

Original PR description

## Summary This PR optimizes memory consumption and execution time when assigning a **Chart of Accounts** or **Fiscal Localization**. By moving filtering logic to the database and preventing…

## Summary
This PR optimizes memory consumption and execution time when assigning a **Chart of Accounts** or **Fiscal Localization**. By moving filtering logic to the database and preventing expensive field prefetching, we've achieved a **60% reduction in peak memory** and cut execution time by more than half on large datasets.

## The Problem
Assigning a chart template was hitting memory limits on databases with a high volume of products (e.g., 2M+). Two main bottlenecks were identified:
* **Inefficient filtering**: Loading all `product.template` <-> `tax` relations into the cache and filtering in-memory using python instead of using SQL.
* **Excessive prefetching**: Accessing `product.product` fields (like `write_date`) inside the compute function triggered a cache miss that prefetched all product fields, consuming significant memory.

## Improvements
* **SQL Filtering:** Pushed the `product_template` filtration logic to the SQL layer to reduce the amount of data loaded into the memory.
* **Prefetching Prevention:** Optimized the compute logic to avoid triggering unnecessary field prefetching on `product.product`.

---

## Benchmarks
*Tested using `memray` on a customer database with ~2 million products.*

| Scenario | Duration | Peak Memory | Total Allocations |
| :--- | :--- | :--- | :--- |
| **Baseline (Before)** | 10:23.4 | 3.6 GB | 9,954,480 |
| **Optimized Prefetching Only** | 10:21.0 | 2.3 GB | 9,292,271 |
| **SQL Filtering Only** | 06:30.2 | 3.0 GB | 8,865,050 |
| **Combined (Final Result)** | **04:59.6** | **1.4 GB** | **8,213,374** |

### Key Results:
* **Memory Saved:** ~2.2 GB (61% reduction)
* **Time Saved:** ~5.5 minutes (52% faster)

OPW-6070666

Before this commit, the action link sent in task email notifications to portal users always redirected to the standard, read-only portal view, even if the user had edit rights to the project via Project Sharing. This commit ensures that: - If a portal user has access to the task and the project has Project Sharing enabled for them, the action URL redirects directly to the editable project sharing view instead of the static portal page. task-5221400

## Summary This PR optimizes memory consumption and execution time when assigning a **Chart of Accounts** or **Fiscal Localization**. By moving filtering logic to the database and preventing expensive field prefetching, we've achieved a **60% reduction in peak memory** and cut execution time by more than half on large datasets. ## The Problem Assigning a chart template was hitting memory limits on databases with a high volume of products (e.g., 2M+). Two main bottlenecks were identified: * **Inefficient filtering**: Loading all `product.template` <-> `tax` relations into the cache and filtering in-memory using python instead of using SQL. * **Excessive prefetching**: Accessing `product.product` fields (like `write_date`) inside the compute function triggered a cache miss that prefetched all product fields, consuming significant memory. ## Improvements * **SQL Filtering:** Pushed the `product_template` filtration logic to the SQL layer to reduce the amount of data loaded into the memory. * **Prefetching Prevention:** Optimized the compute logic to avoid triggering unnecessary field prefetching on `product.product`. --- ## Benchmarks *Tested using `memray` on a customer database with ~2 million products.* | Scenario | Duration | Peak Memory | Total Allocations | | :--- | :--- | :--- | :--- | | **Baseline (Before)** | 10:23.4 | 3.6 GB | 9,954,480 | | **Optimized Prefetching Only** | 10:21.0 | 2.3 GB | 9,292,271 | | **SQL Filtering Only** | 06:30.2 | 3.0 GB | 8,865,050 | | **Combined (Final Result)** | **04:59.6** | **1.4 GB** | **8,213,374** | ### Key Results: * **Memory Saved:** ~2.2 GB (61% reduction) * **Time Saved:** ~5.5 minutes (52% faster) OPW-6070666