Saturday, February 14, 2026
4 changes · 19.0
Resolved issues and error corrections
The manufacturing cost calculation now correctly accounts for work center efficiency when computing a product variant's price from a bill of materials. This prevents underestimating costs for multi-variant products, helping businesses keep product pricing accurate.
Opening the inventory valuation report is now more reliable for very large databases with many average-cost products. The change reduces memory pressure during report calculation, helping businesses access valuation data without crashes.
Original PR description
Related ticket: https://www.odoo.com/odoo/project/49/tasks/5416006 Issue: Opening the inventory valuation report can trigger a memory error under these conditions: 1. There are millions of stock.move records. 2. Many of the products use the average cost method. Explanation: When the inventory valuation report is opened, the total_value of every product is computed. If the product uses the average cost method and there is quantity available, all of the product's stock moves and stock move lines are queried. This can take up too much memory. Solution: To prevent this, we periodically clear the cache for the stock.move and stock.move.line models. opw-5416006 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a problem where editing the address in a website Google Maps block could get stuck and fail. Users can now update the map address normally, improving reliability when building or editing website pages.
Original PR description
When we add the google map block and try to change the address, we're unable to do so because of the infinite loop. The issue is due to the onPlaceChanged call inside the onPlaceChanged. We'll use commitPlace instead to commit place's coordinates, then re-render the map to reflect it. Steps to reproduce: 1. Add a google map block. 2. Try to change the address. It doesn't work due to the maximum call size exceeded due to infinite loop. opw-5386094 Forward-Port-Of: odoo/odoo#243679
This update optimizes the MPS report to run faster and use less memory, especially when processing large production schedules. By reducing the amount of data fetched and minimizing unnecessary queries, the report now handles more complex scenarios without errors. This results in a smoother and more reliable experience for users.
Original PR description
Problem: When running the MPS report on a large number of production schedules, if the associated number of stock moves is high, the _get_moves_and_date method can cause a memory error. Solution: We…
Problem:
When running the MPS report on a large number of production schedules, if the associated number of stock moves is high, the _get_moves_and_date method can cause a memory error.
Solution:
We will fetch only the necessary fields to reduce queries and memory usage and set prefetch_fields=False to further reduce memory usage.
Benchmarks:
Run locally on a dupe of customer's db.
Time/queries measured by requests to /get_mps_view_state Memory measured using memray on method get_production_schedule_view_state()
<table>
<tr>
<th rowspan="2"># of Production Schedules</th>
<th colspan="3">Before</th>
<th colspan="3">After</th>
</tr>
<tr>
<th>Time</th>
<th># of Queries</th>
<th>Memory usage</th>
<th>Time</th>
<th># of Queries</th>
<th>Memory usage</th>
</tr>
<tr>
<td>20</td>
<td>22.846s</td>
<td>1,379</td>
<td>882.0MB</td>
<td>8.046s</td>
<td>1,180</td>
<td>103.4MB</td>
</tr>
<tr>
<td>300</td>
<td>41.098s</td>
<td>6,297</td>
<td>1.0GB</td>
<td>43.694s</td>
<td>5,732</td>
<td>363.5MB</td>
</tr>
<tr>
<td>1000</td>
<td>N/A (MemoryError)</td>
<td>N/A (MemoryError)</td>
<td>>2GB</td>
<td>88.416s</td>
<td>22,629</td>
<td>1.1GB</td>
</tr>
</table>
Average memory usage reduction: 75%
opw-5225472
Forward-Port-Of: odoo/enterprise#106392