Closed (fixed)
Project:
Commerce Coupon (D7)
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
3 Mar 2015 at 00:23 UTC
Updated:
10 Nov 2015 at 14:55 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
joelpittetComment #3
dpolant commentedI'm not so sure about this. If commerce coupon installed correctly, you should definitely have a coupon reference field on all order bundles and this error should not be happening. Did you install Coupons 2.x from an upgrade or from scratch? Were there any problems during installation/upgrade?
Comment #4
joelpittet@dpolant it happens only when I create a cart programmatically. No problems with the upgrade/install.
Looks like this needs a re-roll.
Comment #5
joelpittetI think it only needs a re-roll because there were lots of end of line whitespace errors in the last set of commits.
Comment #6
joelpittetComment #7
joelpittetRe-rolling and slight change to the rules isset() EMW checks.
Used -w flag in git diff because there are lots of ending whitespace issues my editor tries to fix.
Comment #8
joelpittet@dpolant Any chance you'd consider adding tests? I may be able to write one to show this bug. Setting to priority to normal because I don't see others running into this and it was only my quick programmatically generated cart scripts that were throwing this error.
Comment #10
joelpittetOk clean git patch... *shakes fist at testbot*
Comment #11
id.tarzanych commentedAdded code protections to commerce_order_update in commerce_coupon_usage module
That also causes
when Before saving a commerce order Rules event is invoked
Comment #12
joelpittetWhy does the interdiff show this moved?
nit: Extra whitespace.
What is $order->original? I've not seen that in my travels yet.
Comment #13
joelpittetComment #14
torgospizza@joel: It looks like $order->original is created during a status update. See comments for commerce_order_status_update():
Comment #15
joelpittet@torgosPizza and @id.tarzanych so I'm saying that may be unnessasary for the scope of this issue.
Maybe the interdiff is weird but I don't think those changes are necessary and I can't see anything in #11 that I'd keep. I could be wrong though.
Comment #16
joelpittetOk reposting #10 so we can get reviews there. It's fairly quick fix. If the ->original stuff needs to be taken care of maybe it can be in a new issue so this is easier for people to review.
@id.tarzanych feel free to disagree, I'm just trying to finish this issue up to move forward an inch.
Comment #18
torgospizzaI was able to apply the patch manually and the concept seems to work well. Might need a re-roll though.
Related is this #2362799: Clarify and strengthen the logic when checking an order for coupons which may become a duplicate if this patch ends up solving that problem as well.
Comment #19
joelpittetApparently HEAD has moved.
Ensuring all the usages of coupon_count and loops through
$order_wrapper->commerce_couponsare checked.I see a bit more what @id.tarzanych was trying to do. I refactored that a bit to make it a bit more clear to that point (I hope).
Comment #20
joelpittetAlso, there was a bit of duplicate logic happening here for checking if a coupon. But I got that wrong. New patch coming a sec. But curious to know if checking the coupon code can be considered the same as checking the coupon_id?
Comment #21
joelpittetFixed logic
Comment #22
nvahalik commentedJoel, in #22, your patch has patches in it.
Comment #23
joelpittetWhoops, was rushing out the door, apparently I'm not setup to do non-core:P
Now with less patch!
Comment #24
dpolant commentedOK, to summarize:
- There seems to be some consensus that there is a possible case where the order object does not have the commerce_coupons field.
- As torgos mentioned, it could be related to https://www.drupal.org/node/2362799 which is a case about using multiple order bundles (among other things).
Joel's patch seems generally good but it is a large diff. As I looked at it, I think it goes a bit too far in terms of adding protections that in many cases we don't need. Here's a breakdown:
- Checking for commerce_coupons field on the order is good. My commit leaves all of these in.
- Checking for coupon_count on discounts should not be necesssary. I add this property directly to all discount entities: it should always be available and should never throw a wrapper error.
- Checking for $form_state['coupons'] in the discount admin function should not be necessary either. The thinking is that if the coupons module is on, it should always be doing its thing on the discount form.
I'll leave this issue open so anyone grab the latest dev and make sure that it solves their problems. Thanks for the feedback everyone!