Wednesday, April 30, 2025
2 changes · saas-17.4
Resolved issues and error corrections
Cancelling an earlier warehouse transfer now correctly cancels the related next delivery step when the warehouse is configured to do so. This prevents sales deliveries from remaining open after the stock picking they depend on has been cancelled, reducing manual cleanup and fulfillment confusion.
Original PR description
### Steps to reproduce: - In the settings enable Multi-Steps Rules - Inventory > Configuration > Warehouse Management > Warehouses - Put your warehouse in delivery in 2 steps and modify the rules to…
### Steps to reproduce: - In the settings enable Multi-Steps Rules - Inventory > Configuration > Warehouse Management > Warehouses - Put your warehouse in delivery in 2 steps and modify the rules to be in the old pull set up Stock 1-> Output 2-> Customer. - Enable the "Cancel next move" option of the pick rule. - Create an SO for 1 unit of a storable product > This should generate both a pick and a ship move. - Cancel the pick move #### > The ship move was not cancelled ### Cause of the issue: While the moves of the chain are correctly linked and the `move_dest_ids` of the pick move is planed to be cancelled, it does not satisfy the filtering condition of moves that should be cancelled because as it is at the end of the chain it does not have a `move_dest_id` it self: https://github.com/odoo/odoo/blob/eb43cdbfeb3d141283dbd9274fae45bf0bf641db/addons/stock/models/stock_move.py#L1966-L1968 IMO, the condition on the locations should be set between the move we are cancelling and the move we plan to cancel rather than on next step of the chain that might not even exist. Note (fix sale_stock): The forward port of commit 853d9c46fc506564c5c40a2ce7cd14507109a923 has not been merged in 17.2 since its issue was not reproducible in that version. This is because the propagate cancel option was not working properly since the push pull refactor. To merge our change we therefore need to reintroduce the associated `sale_stock` fix. opw-4689175 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers can now add optional products with custom attributes to their cart even when no custom value is entered. This prevents a checkout-flow error and keeps online shopping uninterrupted.
Original PR description
Currently, an exception is raised when a user tries to add a custom product as an optional product for another product and attempts to add it to the cart without providing a custom value. Steps to…
Currently, an exception is raised when a user tries to add a custom product as an optional product for another product and attempts to add it to the cart without providing a custom value. Steps to Reproduce: 1. Install the website_sale module. 2. Go to Website -> eCommerce -> Products. 3. Create a product and add a custom product as an optional product. 4. Navigate to Site -> HomePage -> Shop. 5. Select the newly created product and click Add to Cart, including the optional product that has a custom attribute, but leave the value empty. 6. Click Continue Shopping. 7. An error occurs. Error: `KeyError 'custom_value' ` This issue [1] occurs because when the user selects a custom attribute without providing a custom value, the `product_custom_attribute_values` dictionary does not contain the custom_value key. [1] - https://github.com/odoo/odoo/blob/6a2284ef1e04e9576e44a4be2376f5449bf29dc7/addons/website_sale/models/sale_order.py#L458 This fix resolves the issue by ensuring that if the custom_value key is missing, an empty string is assigned. sentry-5763345162 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr