Closed (fixed)
Project:
Commerce Coupon (D7)
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
12 Nov 2012 at 12:37 UTC
Updated:
15 Feb 2013 at 10:30 UTC
Jump to comment: Most recent file
Comments
Comment #1
googletorp commentedI've added a simple fix to this bug, by comparing the coupon id instead of comparing the actual coupon entity object.
Comment #2
pcambraWrong patch? :)
Comment #3
googletorp commented28 != 82
This is the proper patch.
Comment #4
foopang commentedHi googletorp, thanks for your patch. But it doesn't work for me.
Comment #5
googletorp commented#4 Did you use the proper patch, what doesn't work for you? What did you do, what did you expect and what happened?
Simply saying that the patch doesn't work isn't really any help, unless you give some additional information.
I can add that the current patch is successfully being used in production environment.
Comment #6
vadim.eremeev commentedI had the same issue and seems attached patch fix it. Please review.
Comment #7
foopang commented@googletorp I used your patch at comment #3, the coupon attached to the order would still be there after the commerce_coupon_remove_coupon_from_order function call.
Then I tried vadim.eremeev's patch, it worked!
I later found that the condition check of $original_order <> $order at line 622 failed, because $original_order and $order are actually referring to the same object. I think we should better clone the $order object at line 613 instead of removing the condition check at line 622. Patch attached.
Comment #8
googletorp commented#7 It's a good catch, but it's actually a different bug you are fixing. Like I explained in the description of the issue, the bug I found was when the coupon had unsaved changes. I don't know if the best option is to keep this in the same issue, since is concerns the same function or to split it out into different issues.
Comment #9
pcambraBoth look great, let's fix both in a row, thanks!