This seems to only affect new (anonymous) users who are paying with Credit Card, although PayPal orders also seem to be affected - we only saw one, but it was the same scenario.

Here is the order's log:

21 April 2009 - 4:30pm	-	  * Credit card payment for $15.96 entered by -.
21 April 2009 - 4:30pm	-	  * Checkout message sent to test@test.com.
21 April 2009 - 4:30pm	-	  * Order status changed from In checkout to Completed.

Similarly, the order comments read as such:

Date             User    Message
04/21/2009
4:30:23 PM	-	Authorization and capture  ACCEPTED: This transaction has been approved. Amount: $15.96

04/21/2009
4:30:23 PM	-	Order created through website.

I'm not 100% sure where I think the issue occurs, but I think it's in this bit of code in uc_file_order:

if ($status == variable_get('uc_file_default_order_status', 'completed') &&
          $order->status != $status &&
          $order->uid > 0 &&
          ($order_user = user_load(array('uid' => $order->uid))) !== FALSE) {

Either the uid is 0, or it's because the order status is moving directly to Completed (as indicated in the logs). Completed status is what our File Downloads are set to be activated on. Also telling is the fact that I have to move the order status to Payment Received, and then BACK to Completed, in order for the File Downloads to be released to the user.

So perhaps it's because this snippet takes place in $op='update' - and since $status == $order->status in this case, the uc_file_user_table('allow') method never gets fired, because the conditional is evaluating to FALSE.

I am going to need to test this out more, and to do so I'll be adding a Watchdog entry to the "else" section of that condition, which doesn't exist right now, to see if I can nail down the problem, but I think this is it.

Comments

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

Another thought, perhaps this should be moved into a Workflow_ng action? If I'm not mistaken uc_file has moved into CA for Ubercart 2.x, right?

rszrama’s picture

rszrama commented

Yeah, it's moved into CA for 2.x, but I don't see us making a similar change retroactively for 1.x. Are you using PayPal WPP for credit card payments? If so, it's likely that an IPN is updating the order to payment received before it redirects to the checkout completion page and has a user created/assigned to the order. In that case, $order->uid would still == 0 when the order is updated... which leaves us with a problem. : (

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

Nope, using authorize.net for our CC stuff. It was fairly reproduceable, too. I think we had maybe a dozen or so orders that needed to be switched over? These were all users who were first-time customers, who needed to have their accounts created. My guess is still that it was either the firing order of the hooks, or the fact that the $status was == to the $order->order_status, resulting in that particular condition not getting fired.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Status: Active » Closed (won't fix)

It's too late to do anything with this now Drupal 5 is obsolete.