Daily updates from Odoo
Friday, June 12, 2026
4 changes · 17.0
Resolved issues and error corrections
This update optimizes how Odoo retrieves related mailings during mass campaigns, addressing a performance bottleneck. The previous method was slow and resource-intensive, particularly with large campaigns. This change significantly improves the speed and stability of mass mailing operations.
Original PR description
**Description of the issue/feature this PR addresses:** The method _get_ab_testing_siblings_mailings currently scans all mailings in a campaign to apply a simple filter, which becomes expensive on databases with many large mailings. **Steps to reproduce bug:** 1) Run this script to get [enough sufficiently large mailings](https://gist.github.com/brcut-odoo/bb0d6d334bfe110afe16021d17d1b443) 2) Open one of the mailings and recieve a crash from the _get_ab_testing_siblings_mailings **Current behavior before PR** https://drive.google.com/file/d/19xftvzsGSQ9DxB67LNiLkKApzsD192ax/view?usp=drive_link **Current behavior after PR** https://drive.google.com/file/d/1apTJ0rWTKaATYa67ZmmN-7bKhrw4KuTx/view?usp=drive_link opw-6245908
This update significantly speeds up the calculation of future timesheets based on public holidays. The previous process was slow due to repeated timezone conversions, which has now been optimized to only localize times when absolutely necessary. This improves the responsiveness of the system, especially when managing a large number of employees and holiday schedules.
Original PR description
**Problem:** When creating a new employee, the future timesheets due to public holidays are computed. If the number of public holidays is large (i.e. if the user creates them for each year, several years in the future), then it takes excessively long and the action may not complete. **Cause:** The pytz method `localize` and comparing times with non-static timezones is done repeatedly and unnecessarily which becomes costly with more records. **Solution:** Only localize the time when absolutely necessary (determining the date of the leave in the calendar timezone). **Performance Stats:** |Record count|Time before|Queries before|Time after|Queries after| |------------|-----------|--------------|----------|-------------| |100 |3.1s |393 |0.8s |117 | |1,000 |22.3s |2,090 |1.5s |183 | |10,000 |Timeout |N/A |6.7s |541 | opw-6087422
This update fixes a potential issue where errors during coupon redemption weren't clearly displayed to users. Now, if a coupon redemption fails, an error message will be shown, helping staff quickly identify and resolve problems with loyalty programs. This improves the overall reliability of the point-of-sale system.
This update optimizes the process of validating purchase orders by preventing unnecessary calculations of location weights. By reordering checks, the system avoids calling a computationally intensive method when other conditions already rule out a location. This results in significantly faster validation times, particularly when dealing with a large number of locations.
Original PR description
When checking if a stock.move.line can use a location as destination with the method `_check_can_be_used()`, we start by checking if the incoming products can be stored without exceeding the maximal…
When checking if a stock.move.line can use a location as destination with the method `_check_can_be_used()`, we start by checking if the incoming products can be stored without exceeding the maximal weight of the location. This needs to call the `_get_weight()` method to compute the forecasted weight for the location. This method relies on heavy computations and can become a bottleneck when we need to loop over a high number of locations. In some cases, we can rule out the location based on less expensive conditions that are verified after the weight one. We propose to invert the conditions check order to avoid computing the location weight when other conditions are not met. Steps to reproduce --------------- - Install stock and purchase modules; - Enable storage locations and categories in the settings; - Create a storage category: allow_new_product = same, max_weight=10.0 kg; - Create N locations using this category, parent_id=WH/stock; - Create a putaway rule to each location from WH/stock, for the new storage category and using a product A with a weight of 2 kg; - Create a stock.quant per location to store a product B, weight=2kg; - Create a purchase order with X lines for 1 unit of product A; - Validate the purchase order. The validation should take several seconds to execute as every locations will be rejected due to the storage category, but it will call _get_weight() first. Benchmark --------------- This improvement is very data specific and will be most useful when a lot of locations are using a storage category of type "empty" or "same". In addition, it also relies on the order in which we are treating the locations, if the acceptable locations are the first to be received in the method, it won't need to loop over all of them. The following benchmark was established in a production database in which every 6068 locations are using a category of type "same". | No stock.move.lines | Before PR | After PR | |---------------------|-----------|----------| | 40 | 168 s | 7.3 s | | 72 | 264 s | 12.33 s | When the only condition that can reject locations is the exceeding weight, this modification will slow down the process. However, the time loss in this case is smaller than the gain in the first case. The following benchmark was obtained by validating a purchase 1 line order with only fully filled locations. | No locations | Before PR | After PR | |--------------|-----------|----------| | 500 | 2.02s | 2.37 s | | 2000 | 7.85s | 9.76 s | | 10000 | 39.16 s | 48.86 s | opw-5949370 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr