I believe I found a bug in the uc_order_is_shippable function.
If the order has a product that is determined to be non-shippable via another module's _cart_item function call, such as uc_file_cart_item, and then a second product that is shippable, the returned result of uc_order_is_shippable is FALSE where is should be TRUE. For me, this has resulted in orders which go straight to "Completed" status even though they have items that need to be shipped still. This case could cause trouble for other situations and modules as well. It definitely trips-up the "Update order status upon checkout completion with full payment" when the first item in the order is a file download that is non-shippable and the second item is a product that is shippable. I believe when the order if items is reversed, the bug does not happen. To me this is a major bug.
I have produced a patch for review. My patch was created from 6.x-2.x-dev but also seems to work for 6.x-2.4.
Comment | File | Size | Author |
---|---|---|---|
uc_order.module.patch | 835 bytes | JonMcL | |
Comments
Comment #1
longwavePatch seems incomplete. This is likely a duplicate of one or both of these:
#977682: uc_order_is_shippable doesn't let see if any other modules have a say in the matter of shippability
#613498: uc_product_add_to_cart_data does not respect non-shippable attributes
Comment #2
jstushnoff CreditAttribution: jstushnoff commentedI agree with this patch... if the $result array is not reset for each product loop, the function evaluates to FALSE if the first product in the order is not shippable. In my case uc_file.module sets the first product to non-shippable; subsequent products retain the 'non-shippable' array item in $result, and therefore all evaluate to FALSE.