Sunday, June 14, 2026
2 changes · saas-19.2
Resolved issues and error corrections
This update significantly speeds up the /my/tasks portal page, especially when viewing large numbers of tasks. By optimizing how data is retrieved and sorted, the page now loads much faster, improving user experience and productivity. This change focuses on efficiency within the Odoo system.
Original PR description
The /my/tasks portal page suffered from severe performance degradation with large task. Three key optimizations: 1. ORDER BY: Use project_id.id instead of project_id in sort orders to avoid resolving…
The /my/tasks portal page suffered from severe performance degradation with large task. Three key optimizations: 1. ORDER BY: Use project_id.id instead of project_id in sort orders to avoid resolving through project.project._order 2. Capped count: Replace the unconditional search_count with a capped version (limit=10k pages). Only fetch the full count when the user navigates beyond page 10,000. 3. Milestone check: Use search(limit=1, order='id') to leverage index-only scans. Benchmark (page 1 load): _prepare_tasks_values (milestone + count, excludes lazy main search): | # Tasks | # Projects | Before PR | After PR | |-----------|------------|-----------|----------| | 500,000 | 2,000 | 0.294s | 0.230s | | 1,500,000 | 2,000 | 0.511s | 0.222s | | 3,000,000 | 12,000 | 1.129s | 0.258s | | 6,000,000 | 24,000 | 2.388s | 0.261s | | *6,000,000| 24,000 | 2.015s | 1.976s | *6M measured while navigating last page (full count triggered). Main search query (ORDER BY fix): | # Tasks | # Projects | Before PR | After PR | |-----------|------------|-----------|----------| | 500,000 | 2,000 | 0.525s | 0.013s | | 1,500,000 | 2,000 | 0.685s | 0.017s | | 3,000,000 | 12,000 | 1.479s | 0.040s | | 6,000,000 | 24,000 | 3.121s | 0.043s | | *6,000,000| 24,000 | 7.562s | 3.781s | Planer before: https://explain.dalibo.com/plan/aa47635ecddadfh5 Planer after: https://explain.dalibo.com/plan/d89gg3f5e8ed529b *6M measured while navigating last page (high offset). - opw-5478903 Forward-Port-Of: odoo/odoo#258064
This update resolves an issue where purchase order confirmations would fail when a delivery type didn't associate with a warehouse. The fix ensures that the system correctly identifies the default destination when a warehouse isn't specified, preventing a type error. This improves the reliability of purchase order processing.
Original PR description
Bug introduced in: https://github.com/odoo/odoo/commit/e2efdf75f67e631ed7622bb01c127120e639f6c5 Steps to reproduce: Clear the Warehouse field (set it to False) Create a purchase order Set "Deliver…
Bug introduced in: https://github.com/odoo/odoo/commit/e2efdf75f67e631ed7622bb01c127120e639f6c5
Steps to reproduce: Clear the Warehouse field (set it to False) Create a
purchase order Set "Deliver To" to the operation type with no warehouse
Add any product Confirm the PO → TypeError is raised
Steps to reproduce the bug:
- Have at least 2 warehouses
- Go to Inventory > Configuration > Operation Types > Receipts
- Clear the Warehouse field (set it to False)
- Create a purchase order:
- Set "Deliver To" to the operation type with no warehouse
- Add any product
- Try to confirm the PO
Problem:
A traceback is triggered:
``` return self.parent_path.startswith(other_location.parent_path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: startswith first arg must be str or a tuple of str, not bool
```
`_get_final_location_record` computes `wh_stock_loc` from
`picking_type_id.warehouse_id.lot_stock_id`. When `warehouse_id`
is False (a valid configuration, operation types can be detached from
any warehouse), `lot_stock_id` short-circuits to False
Solution:
guard the _child_of call with not wh_stock_loc. When the
picking type has no warehouse, wh_stock_loc is falsy and there is
nothing to compare against, so the method falls back to
default_location_dest_id (the only destination available).
opw-6253817
Forward-Port-Of: odoo/odoo#268317