Daily updates from Odoo
Thursday, September 4, 2025
6 changes · 18.0
Enhancements to existing features
Point of Sale now avoids loading large sets of product attribute values during startup when they are not immediately needed. This reduces unnecessary data loading and improves performance for businesses with products that have many variants or options.
Original PR description
Before this commit, when loading PoS, all product template attribute value (ptav) IDs linked to a product attribute were loaded. This caused performance issues when attributes had a large number of values, even though they were not needed at that stage. With this commit, the values are no longer preloaded, since the reverse fields in ptav and ptal are fetched when needed, ensuring they can still be linked correctly without degrading performance. opw-5006818 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Imported supplier bills now group invoice lines by tax, so accountants can quickly see which amounts correspond to each tax rate instead of reviewing every individual line. This makes bill review faster and easier while preserving the tax information needed for accounting checks.
Original PR description
[IMP] account_edi_ubl_cii: group imported invoice lines by tax Most of the time, an accountant that imports a bill don't need to see every line. What's useful to him is to see what amount is linked to what tax. task-5047859
Stock replenishment rule lookups are now processed in batches instead of one by one. This reduces delays in workflows that evaluate many products and locations, such as replenishment planning, making larger operations noticeably faster without changing user-facing behavior.
Original PR description
Currrently `product.product._get_rules_from_location` can become a performance bottleneck when it's called multiple times. Because the method finds a candidate stock.rule then call itself recursively…
Currrently `product.product._get_rules_from_location` can become a performance bottleneck when it's called multiple times. Because the method finds a candidate stock.rule then call itself recursively with stock.rule.location_src_id, it's difficult to properly batch. In this commit we introduce two methods, `product.product._get_rules_for_combinations` and `procurement.group._get_rules_for_combinations`. The second one is a batched version of `get_rule`. The idea is that given a list of (products, locations, warehouses), the method will call `search_rules_for_warehouses` only once and then distribute the fetched stock.rule to the correct `(product, location, warehouse)` triplet by building a dictionary. This is then used by `product.product.get_rules_for_combinations` which takes a list of `(products, locations)` pairs and build a recordset of stock.rules for each one. The way to use this workflow is the following: - The calling code creates the list of (product_id, location_id) it needs. E.g. `[(o.product_id, o.location_id) for o in orderpoints)]` - A single call to `product.product._get_rules_for_combinations` - stock.rules are then extracted by the calling code using the resulting dictionary. Assuming the worst case, the current code does (n+k) calls to both `product.product._get_rules_from_location` and `procurement.group._get_rule`, with n being `len([(r.product_id, r.location_id) for r in records])` and k the total number of recursive calls in `product.product._get_rules_from_location` After this commit, the worst case will be h calls to both methods, with h being the height of `product.product._get_rules_for_combinations` recursive call tree. #### speedup Current iterative version product._get_rules_from_location | Total loops count | Exec Time | |:-------------------:|:------------:| | 10 | 50ms | | 50 | 62ms | | 500 | 567ms | | 7 441 | 5.6s | Benchmark of product._get_rules_for_combinations | combinations Nb | Exec Time | |:-------------------:|:-----------:| | 10 | 24 ms | | 50 | 23ms | | 500 | 93ms | | 7 441 | 1.23s | Average speedup calling both method from a shell: 2.4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Documents app now shows files in their default order based on when they were created instead of when they were last changed. This makes document lists and the trash more stable, so small edits like adding tags or upgrade-related updates no longer unexpectedly move items around.
Original PR description
As the write_date can be reset by very small changes like adding a tag, updating its name and also during some upgrade, we set the default ordering to create_date. We do similarly for the trash. Task-5025453
The Master Production Schedule has been optimized to load and update much faster, especially for companies with many schedules and complex bills of materials. This reduces wait times when opening the MPS or changing order quantities, helping planning teams work more efficiently.
Original PR description
Multiple optimizations for the MPS. Utilizes new method `product.product._get_rules_for_combinations`. Memoize results in dictionaries and pass them to method via context/params. Add BFS preprocessing to `_get_indirect_demand_tree` to get boms in batches instead of one component at a time. #### speedup In a database with 1087 schedules and complicated bom structure, Opening the MPS `get_mps_view_state`: - 9.23s -> 4.97s Changing To Order qty in MPS `get_production_schedule_view_state`: - 25s -> 6s
UrbanPiper connection errors now show the actual message returned by the service instead of a generic technical error. This helps teams quickly understand failures, such as duplicate store references, and resolve setup or synchronization issues faster.
Original PR description
Before this commit: --- - HTTP errors from UrbanPiper API only showed the generic Python exception. - It was difficult to identify the actual cause (e.g., duplicate store ref_id). After this commit: --- - HTTP error handling now extracts the `message` from the API JSON response. - The displayed/logged error clearly reflects the real cause of the failure. task-5026169