Daily updates from Odoo
Thursday, January 22, 2026
4 changes · 17.0
Resolved issues and error corrections
This update fixes an issue where the shipping weight for deliveries wasn't accurately calculated when items were placed in packages. The fix ensures that the total package weight is correctly computed, addressing a potential discrepancy in delivery weight reporting. This improves the accuracy of shipping calculations.
Original PR description
Steps to reproduce: - Enable “Packaging” in Inventory settings. - Create a storable product “P1” with: - weight: 10 kg - Create a delivery picking: - Add one unit of P1 - Mark as “To Do” - Set…
Steps to reproduce:
- Enable “Packaging” in Inventory settings.
- Create a storable product “P1” with:
- weight: 10 kg
- Create a delivery picking:
- Add one unit of P1
- Mark as “To Do”
- Set quantity to 1 → the move becomes assigned and the picking weight is correctly computed to 10
- Click “Put in Pack” → a package is created with `shipping_weight = 0`, and the picking weight incorrectly computed to 0
Problem:
- `picking.shipping_weight` is computed as: `weight_bulk` + sum(`pack.shipping_weight or pack.weight`) https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L72-L79
- Once the product is placed in a package:
- `weight_bulk` becomes 0 (because Total weight of products which are not in a package). https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L96
- `pack.shipping_weight` is 0 on creation.
- The fallback `pack.weight` is 0 because its compute depends on the `picking_id` in context. Without this context, the compute uses only quants https://github.com/odoo/odoo/blob/f7c033eff7b7bc83d6d18fc5e4df320f43ae5021/addons/delivery/models/stock_quant_package.py#L11-L13
opw-5357843This update fixes a bug that prevented the dashboard from accurately displaying high-priority maintenance requests. The issue stemmed from a misinterpretation of the priority field's data type, leading to an incorrect count of zero. Now, high-priority requests are correctly identified and displayed, improving maintenance prioritization.
Original PR description
Issue before this commit: ========================= The high-priority maintenance request count (todo_request_count_high_priority) was not calculated correctly. Steps to Reproduce:…
Issue before this commit: ========================= The high-priority maintenance request count (todo_request_count_high_priority) was not calculated correctly. Steps to Reproduce: ========================= - Install the maintenance module. - Create a maintenance request and set the Priority to High (3-starred) in the form view. - Open the dashboard. - Observe that the high-priority request count is not displayed. - The count always remains 0, even when high-priority requests exist. Cause of the issue: ========================= In this [PR](https://github.com/odoo/odoo/pull/94866), the logic was mistakenly changed. The priority field is defined as a Selection field, but while computing the count, the comparison was done against an integer(3, not '3') instead of the actual string value. Since the stored value is '3' (string), the condition is always evaluated to False, resulting in a count of 0. With This Commit: ========================= Ensure that high-priority maintenance requests are correctly counted and displayed on the dashboard when they exist. This provides better visibility of critical requests and helps users prioritise maintenance work effectively.
This update enhances the stability of the account winbooks import process. Previously, the function could consume excessive memory when creating a large number of moves at once. This change splits the process into smaller batches, preventing memory issues and ensuring smoother imports.
Original PR description
The part of the import function that created moves could easily attempt to create thousands of moves at once, potentially leading to a memory error. This PR splits the calls into batches to avoid using too much memory. opw-5003045 Forward-Port-Of: odoo/enterprise#91931
This update resolves an issue where refunding orders could fail due to missing product information. The change ensures that product details are loaded before refunding, preventing errors and improving the reliability of the point-of-sale refund process. This enhances the overall customer experience.
Original PR description
Before this commit, it was possible the cached toRefundLines included orderlines whose products were not loaded in the POS. This would cause an error when refunding another order for the same partner. This commit ensures that the product is loaded before refunding an orderline by using a new method in the POS store that loads the product if it is not already present in the database. opw-5384010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr