Roles and File Downloads Not Being Assigned for Anonymous Checkouts

BenK,

Drupals authentication system gives all users the same uid(0), which is also the unique identifier for users. If you were to grand the anonymous user additional privileges, or file downloads, they would be available to all anonymous users, which would defeat the purpose of restricting the content in the first place.

I would recommend you check the "Login users when new customer accounts are created at checkout." box on the admin/store/settings/checkout/edit page

If this does not solve the problem, please report back and change the status.

BenK,

Are you testing this with the credit card test gateway?

Changing the title should help me remember that this isn't by design.

I haven't been able to reproduce this. I used auth.net as well to see if that somehow was triggering the problem. I'm not sure what the issue is here...

subscribing

have had trouble with automatic role assignment for anonymous users who buy a membership with recurring fees paid through paypal

planning to investigate the problem in a few weeks when I have some more time

Folks,

Any luck on this .... ????

It sounds to me like the role is being granted before a user exists to receive it. Unfortunately, this can happen very easily. By default, when payment is made in full for an order, it is moved to the "Payment received" status. Also, by default, files and roles are granted when the order reaches the "Completed" status. If the order isn't shippable, and it has been completely paid for by the time the "checkout is complete" trigger fires, then it is moved to the "Completed" status.

The problem is that payment is made before the "checkout complete" event. This event takes care of processing the associated predicates, but it also creates or logs in the user and fires off the order and account confirmation emails. If the file and role granting predicates are changed to run when the order hits the "Payment received" status, then it won't work for anonymous users they don't have their own user account yet.

So the question is if the conditions and triggers are set up in such a way that the roles are being granted before the proper time.

I would say to change the predicates around so that when checkout is complete, and the order balance is 0 (or less), then update the status to payment received. Disable the predicate that is triggered when payment is received. Of course, this means you have to change the order status manually if you receive payment sometime after the order is placed, but I don't think that is too onerous.

Actually, it's probably best if the default predicates did the most reasonable thing in the first place. I'd like to set files and roles to be granted on "Payment received", but those modules aren't dependent on uc_payment, so I can't be sure that status exists all the time. It would be nice to have a hook_ca_predicates_alter() so that uc_payment can change the status conditions, but this way it's really only necessary for shippable orders. I think most people who sell files and roles on shippable products should know to change the default condition.

It'd be good if I can copy, paste, and then modify correctly. Updates shippable orders to the correct order status now.

It sets up a predicate to change the order status to "Payment received" on the "customer completes checkout" trigger, when the order balance is 0 or less. On its own, that's not a big change, but it allows people to change the file and role granting predicates to trigger of the change to the "Payment received" status.

Actually, this patch makes sure there are two of these predicates. One for shippable orders puts them in "Payment received", and the other for non-shippable puts them in "Completed".

It might be a good idea to do the same thing for the file and role granting predicates, to make one for shippable orders and one for non-shippable orders. Granting files twice is something to avoid.

So, do I understand this right that what we need is 3 new conditional actions, and modifications to 2 of the existing ones?

Add 3 new cas:

When checkout complete, balance <= $0.00, and shippable:
Update to Payment received (a second time)
This will trigger the other two new ca’s below.

When order updated to payment received, and order user not anonymous, and shippable
grant/renew purchased roles
The not anonymous will keep it from prematurely triggering on the first change to Payment received (that occurs before the new user exists).

When order updated to payment received, and order user not anonymous, and shippable
grant/renew purchased files
The not anonymous will keep it from prematurely triggering on the first change to Payment received (that occurs before the new user exists).

Change 2 cas:

When order updated to completed (from non-completed), and not shippable
grant/renew purchased roles
Adding not shippable will prevent shippable orders (handled above) from being triggered again when they are marked as completed.

When order updated to completed (from non-completed), and not shippable
grant/renew purchased files
Adding not shippable will prevent shippable orders (handled above) from being triggered again when they are marked as completed.

Does that cover all the paths of execution for combinations of anonymous and logged-in customers, shippable and non-shippable, instant payment or delayed (check/COD)?

The only holes that I see are if

a. customer orders only non-shippable and pays by check (order goes to Pending); admin enters check payment (goes to Payment received), but doesn't manually set it to Completed (roles/files never triggered).

b. customer orders mix of shippable products and memberships/downloads and pays by check (order goes to Pending); admin skips entering payment (because they handle it in their accounting software instead, for instance) and just manually sets the order status to Completed (roles/files never triggered since for shippable orders it happens on Payment received).

c. admin manually sets an order with mix of shippable and role/file products to some other status then back to Payment received (would cause the role/file triggers to run again)

Might be reasonable to store somewhere in the database whether or not files/roles had been granted for an order, and make a condition that checks that instead of just going based on order status and shippability.

Subscribing!

subscribing

RSTaylor, I think I would avoid putting the order into Payment Received the first time. Since all of the actions can happen for authenticated users at the second time just as well, it seems less complicated to do everything then. Then, the only extra conditions that need to be added are to check that the order still isn't in checkout.

With a system like this that relies so much on user input, we can't make it completely fool-proof. Admins will probably always have to make adjustments to whatever default predicates Ubercart gives them, too.

subscribing

So, I just tested file downloads with an anonymous user who had no account on the 2.x Livetest. I had updated to the latest code from Bazaar and everything worked without this patch. I'm going to mark this duplicate, but if you can reproduce the bug with the latest code from Bazaar (or what will be 2.0-RC7) then open this.

Related issue: #487698: Not getting order notification e-mails - Checkout completion action not triggered?

I was keen to test this on 2.x livetest re a premium node access but there does not seem to be that type of product on test. I am happy to test this for us in this context but dont have access to the latest code from Bazaar and RC7 is not yet available. Could I request a link to this code joe@venturacottage.com - thanks

Use this link to download the latest code http://bazaar.ubercart.org/ubercart6-2-bzr.tar.gz, this is an hourly snapshot

Having updated my site to Drupal 6.14 and Ubercart 6.x-2.0-rc6 all was FINE I went to http://94.3.209.241/uberdrupal11/another-vid-333-product > [Add to Cart] > [Checkout] (not google checkout) > scrolled to bottom of page To check Payment method > all ok and order fine using test cc 4111111111111111 BUT then updated to http://bazaar.ubercart.org/ubercart6-2-bzr.tar.gz and repeated the above now I just get a long progress bar and cannot complete the order

I will leave the site http://94.3.209.241/uberdrupal11/another-vid-333-product to allow you to see the result - Should I report this elsewhere as well??

The report warning shows

Type	page not found
Date	Wednesday, September 23, 2009 - 18:30
User	Anonymous
Location	http://localhost/uberdrupal11/cart/cart/checkout/payment_details/credit
Referrer	http://localhost/uberdrupal11/cart/checkout
Message	cart/cart/checkout/payment_details/credit
Severity	warning
Hostname	127.0.0.1

but this disapears if I do a db restore and return to rc6

artatac, I think you need to open a new issue. I don't see how that's related to this one. There are usually external issues that cause progress bars to scroll indefinitely.

ok - have done

at http://94.3.209.241/uber01 I started again with a clean install > created premium content
http://94.3.209.241/uber01/setting-ubercart-2-site-video-part-1 (which hopefully you wont be able to get to!

so if you go to the product http://94.3.209.241/uber01/setting-ubercart-2-site-part-1 > choose the premium format > add to cart > checkout > Fill in the sales form using test creditcard 4111111111111111 > review order > submit order

It will sign you in, send you the emails but will not give you access to the premium content above UNTIL you repeat the process above now you are signed in..

The implication of the discussions above was that rc7 has now sorted this. Once again to help this is only a demo site so if you want to look at settings, user1 name and password are
webmaster
demo

I just created an order (order #7) and you're right, I don't see the files under the "My Files" area. (user/#/purchased-files). What order status did the order get set to? I don't even see my order in my order history, nor do I see an "Orders" tab. Usually I can at least see that in a new install, but your site shows neither.. hmm...

But if you now ensure you are logged in and buy again all will work. Including a my premium content block appearing on the lhs

Could I ask you to consider the issues with anon users and node access as well - in your thinking

Thanks

Joe

I think I am facing the same issue, but could we clarify the meaning of an anonymous user?

An anonymous user as defined by Drupal is uid 0! I don't think that is what most people mean here though, and I also think it is not a good idea to enable anonymous users (as per Drupal's definition) the download files permission, as then the link can be sent around and anyone can download the file... Try it out.

I believe I identified a bug closely related:
#658470: User is not logged in with "Enable anonymous checkout" + Paypal WPS
Posted it as a new issue not to hijack this one, if they are unrelated.

subscribing

#40: That's why Ubercart has limitations in place. You can choose to limit a certain # of IP addresses from downloading each link, or after a certain amount of time - so the damage is minimized.

this is an odd behavior - even I deleted the first condition on "Grant or renew purchased roles" (as BenK mentioned in his post #39 above) my users won't granted the role. Checked MySQL logs and found that the role gets deleted from the table user_roles!!! Just take a look:

Here's what I found in my MySQL log ... the user's uid = 2448 (or 0 before = anonymous)

SELECT * FROM ca_predicates WHERE ca_trigger = 'uc_order_status_update'
SELECT * FROM users u WHERE uid = 0
SELECT r.rid, r.name FROM role r INNER JOIN users_roles ur ON ur.rid = r.rid WHERE ur.uid = 0
SELECT f.name, f.type, v.value FROM profile_fields f INNER JOIN profile_values v ON f.fid = v.fid WHERE uid = 0
SELECT * FROM uc_roles_products WHERE nid = 109
SELECT * FROM uc_roles_expirations WHERE uid = 0 AND rid = 4
SELECT * FROM role ORDER BY name
UPDATE uc_roles_expirations SET expiration = 1456159794 WHERE uid = 0 AND rid = 4
SELECT * FROM uc_roles_expirations WHERE uid = 0 AND rid = 4
INSERT INTO uc_order_admin_comments (order_id, uid, message, created) VALUES (17, 0, 'Customer user role subscriber renewed.', 1265653954)

...
...
...

DELETE FROM users_roles WHERE uid = 2448

For me it seems the already set user role gets deleted at the end - Anyone knows why that happens?

I need to get the anonymous registration/grant role to work - and u know what? It worked for me yesterday but can't figure out what changed the procedure.

Thanx,
higgins

oh, and btw - I'm using Ubercart 6.x-2.2

Will downgrade to 6.x-2.0-rc3 ... let u guys know how it turned out.

ok folks - downgrading to Ubercart version 6.x-2.0-rc3 did the trick!!!

if u come up with a different approach let me know - thanx, chris

I applied the patch in 18 and changed conditional actions to handle shippable and non shippable orders separately.

Worked great. Thank you very much.

Can this be committed please?

thanks,

Joe

@joestewart: It's good to hear that you have it working. Were you having the same problem as the original poster *before* you applied the patch? And what exactly did you test? File granting? Role granting? Both? What order status condition did you trigger on? What payment method are you using?

I think it's still very unclear whether #18 fixes things or not. To summarize, we have at least one report #27 that says #18 didn't make a difference, and one report #39 from the original poster who said #18 didn't fix things, and another report #39 also from the OP that said he got it partially working, though the implication is that something other than the patch in #18 was the fix.

Before I commit this I want to hear, at the very least, confirmation from the OP that #18 (and just #18, nothing else needed) fixed his problem. There are also additional concerns raised in #21 that haven't been answered.

@TR Thanks for the response. Looking at it again yes my post was too vague. I had more and I deleted too much.

I understand that this may not be the complete or end solution. But it did correct my problem.

It does look like my situation is similar to the OP as stated in #15. Before the patch, role granting was working with orders that had no shippable items. But if an order also contained a shippable item, the order goes to payment_received and the role is not granted at that time.

The report in #27 doesn't state that it was tested with shippable items. It seemed to be more of a report that the existing code was working for him.

Yes, I didn't see where #39 stated that he had applied the patch. But it also doesn't state that he got shippable items working with payment_received either.

I had to apply the patch in #18 and have two conditional actions for role granting as described in #20. One for shippable items that checks in payment_received and one for non shippable that checks when complete.

thanks for your help,

Joe

I was having similar issues with shippable items.

I also found that the client changed the SKU in the product. The product feature, however, still listed the old SKU. When I edited the feature, the SKU defaulted to "any". I updated it to the new SKU, saved the feature, and then the roles were granted properly. I also removed the "shippable" flag from the product, so I'm not sure which action actually solved the problem.

Subscribing. I'm on UC 6.x-2.2 and also not seeing file permission emails sent for anonymous users. I'm going to try the patch in #18 and will report back.

I've tested the patch in #18 quite extensively for non-shippable role products, and it works quite well both on development and production environments. I'd love to see this committed soon as uc_roles is more or less rendered useless without this (for anonymous users).

#18 is not working.

Any one suggest me, how can i get working file to assign role to anonymous user after checkout using role assignment feature.

Thanks in advance.

@morningtime - after applying #18, you also need a similar conditional action that acts when the order is payment_received.

Nevermind, not worth it... good luck, guys.

I've been trying to get anonymous users to have a role attached to their new user account on checkout, the problem I was having was that their orders were staying as "in-checkout". The order needed to complete for the role to be attached to the user's account.
I tried adding and changing conditional actions as suggested above with no effect.
I finally got it working by going to: store administration > configuration > checkout settings settings > edit
Under Checkout completion settings, untick the box that says "Login users when new customer accounts are created at checkout." and save configuration.

When performing an anonymous checkout, I now get directed to a confirmation page (which I wasn't before) the role is added to the new user account and the order status is "completed".
The only niggle is that the user will have to login, but that's hardly a problem!

As I understand it (after walking through the code in xdebug) is that for anonymous users, when uc_roles.ca.inc does its role grant/renew, it does it on the anonymous user object, because even with all those config items mentioned above, the user is getting creating later in the checkout process, and at that point the roles to be granted (along with expiration date) has been discarded.

So if the user gets created earlier, everything works as it should. So I just made a small module that calls hook_order, so that the user gets created earlier in the process. The actual user create code is lifted straight from line 1227 in uc_cart.module.

function custom_checkout_order($op, &$arg1, $arg2) {

  switch ($op) {
    case 'submit':
     custom_checkout_createnewuser($arg1);
      break;
  }
}

/**
 *
 * Check if the person placing the order has an account on the site. If not, create one for them.
 * This function is taken from 1227 in uc_cart.module 
 */
function custom_checkout_createnewuser($order){
if ($order->uid == 0) {
    // Check for an existing user account with the e-mail address from checkout.
    $result = db_query("SELECT uid FROM {users} WHERE mail = '%s'", $order->primary_email);

    // If it was found, update the order.
    if ($account = db_fetch_object($result)) {
      $order->uid = $account->uid;
      $account = user_load($account->uid);
      db_query("UPDATE {uc_orders} SET uid = %d WHERE order_id = %d", $order->uid, $order->order_id);
      $message_type = 'existing_user';
    }
    else {
      // Get a valid new username.
      if (empty($order->data['new_user']['name'])) {
        $name = uc_store_email_to_username($order->primary_email);
      }
      else {
        $name = $order->data['new_user']['name'];
      }

      // Setup the account fields array and save it as a new user.
      $fields = array(
        'name' => $name,
        'mail' => $order->primary_email,
        'init' => $order->primary_email,
        'pass' => empty($order->data['new_user']['pass']) ? user_password(variable_get('uc_pwd_length', 6)) : $order->data['new_user']['pass'],
        'roles' => array(),
        'status' => variable_get('uc_new_customer_status_active', TRUE) ? 1 : 0,
      );
      $account = user_save('', $fields);

      // Send the customer their account details if enabled.
      if (variable_get('uc_new_customer_email', TRUE)) {
        // Manually set the password so it appears in the e-mail.
        $account->password = $fields['pass'];

        // Send the e-mail through the user module.
        drupal_mail('user', 'register_no_approval_required', $order->primary_email, NULL, array('account' => $account), uc_store_email_from());
      }

      // Store the login details in the session for use on the page display.
      $_SESSION['new_user'] = array('name' => $fields['name'], 'pass' => $fields['pass']);

      // Update the order's uid in this request and in the database.
      $order->uid = $account->uid;
      unset($order->data['new_user']['pass']);
      db_query("UPDATE {uc_orders} SET uid = %d, data = '%s' WHERE order_id = %d", $order->uid, serialize($order->data), $order->order_id);

      // Login the user if specified.
      if ($login) {
        $form_state = array('values' => $fields);
        drupal_execute('user_login', $form_state);
      }

      $message_type = 'new_user';
    }
  }
}

Subscribing.

Hi banani,
thank you for your code ... but i don't uderstand where i must to put it exactly ...
I know make some simple module like 'block' or specific page but in this case i dont 'understand how i can interact with the hook_order thank !

A patch that may help fix this is in #644538-231: Duplicate order notification e-mail, and duplicate stock decrement.

This ensures that users are created first, and then orders move from in_checkout to payment_received and then to completed if there were no shippable items. If that patch works, it should be possible to change the default file and role predicates to trigger on "payment received" instead of "completed", so files and roles are granted as soon as payment is received even if there are shippable items in the order.

A new patch in #644538-291: Duplicate order notification e-mail, and duplicate stock decrement also attempts to fix this, it does it with other changes than in #63, because that one didn't work properly on other use cases.

Hey kanani, slick solution. It doesn't work for me though. Does your cool little module work for you? I used your code in a module on my box and I've got loads of watchdogs all throughout the module you've provided and they record things that I'd expect them to record, but still no role gets assigned to the user.

Did you end up doing anything else to make anonymous users auto-login-and-get-the-role-they-just-purchased? I'm using ubercart 2.4.

P.S. how's cross-fit going?

-James

Using your slick module, but with the 'save' $op instead of 'submit' fixed my problem. At least upon initial testing. I'm running ubercart 2.4, not 2.2 though, so that might account for the needed $op change.

Thanks man, awesome idea.

-James

@jameswoods, Would you be willing to test the patch(es) that hanoii linked to above? Would be interested to know if we can fix this in the module as it stands now, rather than installing yet another module to take care of functionality that should be working in core UC. Thanks!

Glad it worked. Probably a minor difference in how we're using the code.

subscribing, trying to setup a subscription site where anonymous users aren't getting the roles they buy.

subscribing. Most important fix I currently need for Ubercart 6.

I'm willing to ditch all the conditional actions on my site and have some that are actually functional. For me & my client this is important to get the site workflow working correctly.

sub

A patch has been uploaded in #1192018-79: Duplicate order notification e-mail, and duplicate stock decrement that should fix this, please test and report back in that issue.

This has been fixed in 6.x-2.x-dev as part of #1192018: Duplicate order notification e-mail, and duplicate stock decrement