Not sure why this happened, but one of our customers had two orders get commission applied that probably shouldn't have. The orders both were attributed to "Unknown", and the status was "In Checkout".. But in the store administration page, the orders did not exist. They must've been declined or canceled or something.

Our system is set to apply commission on "Completed" and "Payment Received" orders. Don't know why this occurred. Perhaps this should even be "Critical" Priority?

Comments

univate’s picture

Status: Active » Postponed (maintainer needs more info)

There is not enough detail here to replicate the bug.

Offlein’s picture

:( I regret that we no longer use the Affiliate module, so I won't be able to generate more info. I guess you can close this?

akay’s picture

Status: Postponed (maintainer needs more info) » Needs review

I can confirm the existence of this bug on a site that was recently launched.

Line 431 of uc_affiliate2.admin.inc should include the following to limit the scope of orders joined by the query. Without this, I see that orders in 'In Checkout' status are credited on the commissions report:

and uo.order_status = "completed"

Note that without this fix, site owners will pay out too much in commissions. That is, the bug has financial implications and should be patched/released asap.

jayemel’s picture

I can also confirm the existence of this bug in a testing environment.

I replicated it by
1. going through the order process up to the "review" point.
2. Not completing the order, but going back and adding more products to my cart.
3. Get to review point again
4. "orders" for the affiliate at /admin/store/affiliate is incremented, despite the sale not completing.
5. Repeat 2, 3, "orders" column for the affiliate gets incremented each time, despite the sale not completing.

It's worth noting however that the report for the affiliate at /admin/store/affiliate/reports does NOT show an increase in columns 'sales' and 'commission' -- i.e. it seems only the "orders" column gets incremented erroneously.

The issue is with function uc_affiliate2_order (implementation of hook_order), line 615 in uc_affiliate2.module. The function adds an order for the affiliate without checking the status of the order.

vmi’s picture

Is there a patch available for this issue or will one be posted?

vmi’s picture

@Offlein - Is there a better alternate module that you've opted for instead?

nohup’s picture

@jmljunior,

Thanks for the detailed report.

@jmljunior,@vmi,

Instead of adding the order as soon as it is created i.e "new", now the order is added to the affiliate when the order is "submitted". Please checkout the code from git or wait for drupal.org to create a new 6.x-2.x-dev release.

Offlein’s picture

VMI, actually, no. Under pressure from higher-ups in the company we went to go use iDevAffiliate, which claimed it "integrates with Ubercart." This is as close to a lie as possible without being one. iDevAffiliate integrates using [only] a tracking pixel, and it kept bugging out on you. And also it meant that if someone finished their order and then refreshed the "Thank you" page a new affiliate commission was generated in iDev. Awesome.

Our affiliate program is basically non-existent right now, but I can assure you that iDevAffiliate was a mistake and that I wished we'd worked more with UC_Affiliate and maybe contributed back if there had been something that was really "wrong" that we noticed.

vmi’s picture

@nohup
Thanks for your suggestion.
I used git to checkout 6.x-2.x-dev and successfully tested the steps outlined in comment #4 by @jmljunior.

@jmljunior
Even though I went back from the Review Order page to add more products (3x) and remove them before submitting to complete my order for 1x the affiliate report @ /admin/store/affiliate/reports reflected only one order as expected. Thanks!

@Offlein
Thanks for sharing and sorry to hear about your unpleasant experience. As far as I can tell - as it stands (pending further testing)- this module performs as intended to meet my needs. I realize your decision to discontinue the usage of this module was posted about a year ago -- based on your experience are there any prohibitive pitfalls / gotchas I should anticipate here that you can think of?

Offlein’s picture

Hello. In a business sense, having and promoting our Affiliate program stopped being a priority, so we simply haven't used iDev or UC_Affiliate2 at all. Just haven't moved back into it.

There was, in fact, no good reason to STOP using uc_affiliate2, actually. I had outside pressure from people that didn't fully think about this stuff.

In th eend, I think there may have been two "aspects" of iDevAffiliate that made it seem superior to uc_affiliate2 [at the time]. One was that iDev lets you pay out to your affiliates automatically via a Paypal account. The other was that our site is a paid membership site - and that's what people were promoting. You cannot create an account on our site without paying for one. Except uc_affiliate2 uses Drupal users as affiliates. So we were creating users that only "sort of" had access to the site just to be Affiliates, and it was confusing in many ways.

djg_tram’s picture

Priority: Normal » Major
Status: Needs review » Active

This is very easy to fix and it's an actual bug all right (and I consider it a major one, if you don't mind my advancing it to such).

Line 712 of uc_affiliate2.module reads the statuses:

$statuses = variable_get('affiliate_commission_order_statuses', array('completed' => 'completed'));

Line 761 then tries to check

if ($op == 'update' && isset($statuses[$status]) && !isset($statuses[$order->order_status])) {

but it's trivially wrong because it only checks for the existence of the key, not its actual value. The key is always present in the array, just its value is zero. So, either use array_filter() when reading the array in the first line mentioned or also check for $statuses[$status] in the second line.

Edit: Sorry, I didn't realize this was for the 6.x version. However, the problem is still present in 7.x, the line numbers are from this version.

moxojo’s picture

Version: 6.x-2.x-dev » 7.x-1.x-dev

For those on 7.x I created a patch that fixes this problem and another issue. See https://drupal.org/node/1754452#comment-7765197

It needs to be tested.

moxojo’s picture

Version: 7.x-1.x-dev » 6.x-2.x-dev

Accidentally set the version to 7.x. Setting it back to 6.x