Using version Drupal 6.22, Ubercart 2.7
Example kit:
Main component: $99.95
Free item #1: (reg $8.95)
Free item #2: (reg $19.95)
Use case #1 - Set the discount fields with no Total Price set
Total Price: blank
Free item #1 discount: -8.95
Free item #2 discount: -19.95
This works great UNTIL I update/save any of the products in the kit, at which point the discount fields are BLANKED and the kit price goes back up to the total with no discount.
Use case #2 - Set the Total Price AND product discount fields
Total Price: 99.95
Free item #1 discount: -8.95
Free item #2 discount: -19.95
Save the kit and re-open it - all discount fields are overwritten so that the discount is SHARED between all components in the kit. I didn't realize this before, but this is how it is SUPPOSED TO WORK. Hideously confusing, but that's a usability issue, apparently NOT a bug.
Marking as major. Stores with product kits could suddenly find that many or all of them are completely out of whack after an upgrade and subsequent product editing. The discount data is LOST and must be re-entered after any update to a component product.
Comment | File | Size | Author |
---|---|---|---|
#2 | 1387638-product-kit-discount-blanking-2.patch | 2.13 KB | wodenx |
#1 | product_kit_qty_discount_blanking-1387638-1.patch | 797 bytes | millenniumtree |
Comments
Comment #1
millenniumtreeHere's a patch. It loads the $node->items array from the database if it does not already exist in uc_product_kit_update() (this is the case when a component product in a kit is saved and triggers a kit node update.
Tests performed:
* Entering a total value overrides the product discount fields as intended
* Entered individual product discounts (with no total value) are saved as before
* Modifying a component product forces an update to each product kit but now correctly saves qty, discount, and ordering fields, which were blanked before.
Please could someone else test this patch so it can move forward. Thanks.
Comment #2
wodenx CreditAttribution: wodenx commentedI don't think we need the extra query - the data for the items array are already present in $node->products. Please try this patch and see if it solves problem #1 above.
Regarding, problem #2 - that's really a separate issue. However, can you suggest an improvement to the current description of this behavior on the form, which currently reads:
Comment #3
wodenx CreditAttribution: wodenx commentedComment #4
millenniumtreeRegarding my use case #2 - I think it would be a better method to hide the discount boxes if Total Price is entered.
Another nice feature would be to have a 'Free' checkbox next to the product discount boxes that automatically negated the price of that product, even if you increase/decrease the product price in the future. *shrug*
Just some usability thoughts - not that important as long as it works. The description text is fine for now, but while I was investigating the bug, I missed reading that bit and thought it was even more broken than it was.
I'll check out the modified patch a little later.
Comment #5
vdupom CreditAttribution: vdupom commentedPatch at #2 solved use case #1 for me.
Thanks
Comment #6
philsward CreditAttribution: philsward commentedAnybody know if this has been committed? I'm also getting the same bug in 2.9... I was hoping it would be fixed by 2.9, but it still isn't...
The other thing that hasn't been mentioned (and might be fixed in the patch which I haven't tried yet) is that the product quantity resets to a value of 1 as well.
Update: Noticed after the fact that the "qty" issue is mentioned in the title... sorry for overlooking...
Comment #7
philsward CreditAttribution: philsward commentedJust applied the patch from #2 and I can also confirm it is all working as intended, including the quantities. Hope to see this added to 2.10!
Comment #8
longwaveCommitted #2 to 6.x-2.x with a minor whitespace fix, likely needs porting to 7.x-3.x.
Comment #9
longwaveI just tested use case #1 in 7.x and it already works as expected - the qty and discounts are kept and not reset - so this has already been fixed there. I think this was done in #473572-8: Problem with drupal_execute in uc_product_kit_nodeapi where Island Usurper describes an issue very similar to this one, but it was never backported to 6.x.
Comment #10
TR CreditAttribution: TR commentedCorrected spelling in issue title so this can be found easier with a search.