I have a conditional action set up to apply a discount to a specific product for people with the appropriate role. It seems to work properly in the checkout process, and charges them the correct amount, but when I am viewing orders through the order administration, the orders seem to be showing pricing and discounts based on the roles that I have assigned to myself as an administrator. For instance, if an anonymous user purchases a product that is set up to be discounted for users with role A, they do not receive the discount. But because my admin account is assigned role A, when I look back at their order, I am seeing that they received the discounted price on every line but the actual transaction line. Conversely, if someone with role A purchases the product, they receive the discount, but I will show that they did not if I do not have role A assigned to myself.
Comment | File | Size | Author |
---|---|---|---|
#14 | 1015054-14.uc_discount.apply-for-correct-account.patch | 2.31 KB | joachim |
#10 | uc_discount.patch | 2.21 KB | mcarrera |
Comments
Comment #1
joachim CreditAttribution: joachim commentedInteresting. Sounds like a bug I've seen, but I hadn't spotted that the current user's roles were being used.
There's probably a place in the code where the global $user object is being used, and shouldn't be.
Comment #2
davident CreditAttribution: davident commentedI can also confirm this behavior.
A user with a specified role discount is shown the discount at checkout, but the admin page shows no discounts.
Comment #3
mcarrera CreditAttribution: mcarrera commentedI confirm the same. I am giving discount on each product, based on user role. As admin I see orders have a different total, based on the role the admin user. I am going to look for global $user as suggested in #1
Comment #4
mcarrera CreditAttribution: mcarrera commentedThe culprit should be the function uc_discount_price_handler_alter which contains a global $user.
I guess a workable solution is adding those lines to the function
if($user->uid != $context['subject']['order']->uid)
$my_user = user_load($context['subject']['order']->uid); // somebody is watching somebody else's order
else
$my_user = $user;
replacing any occurrence (there is actually 1 in my version) of $user in such function with $my_user .
Comment #5
davident CreditAttribution: davident commentedI can confirm that this code will fix the issue. Replace uc_discount_price_handler_alter() with the following code in uc_discount.module. Clear caches and you're on your way.
Comment #6
joachim CreditAttribution: joachim commentedNice work finding the bug, mcarrera!
Does anyone have time to make a patch of that change so it's easier to test it out?
Also, usual practice for a user account that might not be the current user is to call it $account.
Comment #7
joachim CreditAttribution: joachim commented@davident: thanks! This needs to be posted as a patch so that it can be reviewed though -- also note Drupal coding standards to do with things like always bracketing if and else blocks, spacing, and indentation.
Comment #8
mcarrera CreditAttribution: mcarrera commentedHello, the following piece of code is bogus, as it doesn't work for product discounts (compared to order discounts for which it should be fine)
problem is $context['subject']['order'] doesn't exist when you are just watching a product. So, if like in my case, you are giving a discount on products based on user role, no discount will be applied.
A workaround I found is
Comment #9
joachim CreditAttribution: joachim commentedInteresting stuff, and thanks for looking at it.
But could people please post patches too?
Comment #10
mcarrera CreditAttribution: mcarrera commentedOk, here is a patch for the changes as at #8
Comment #11
mcarrera CreditAttribution: mcarrera commentedComment #12
mcarrera CreditAttribution: mcarrera commentedDid anybody had a chance to test the above patch? I applied it in a pilot project which never went on production
Comment #13
ar-jan CreditAttribution: ar-jan commentedI tested the patch and it works as advertised.
Comment #14
joachim CreditAttribution: joachim commentedIs this bit actually related to this bug, or is it a fix for something else? Could someone confirm?
In the meantime, here's a reroll for code style and comments.