Product Key visible in my account when order status is pending

Yes, I agree this sounds like the "COD payment" issue.

Perhaps there is a way to fix this. The question is: when do you give the user the product key? My answer so far has been: when the order is completed. This is because I've been thinking of the order process mostly in terms of checkout.

In another bug report, someone pointed out that admin-created orders never issued a product key. Again, this was because I was just thinking of checkout, rather than thinking of the entire life-cycle of the order.

I fixed the admin orders by issuing keys to any product order where the order state transitions from anything to 'completed' AND the order currently has no product keys associated with it.

So I've removed the hook_order_complete() function and now handle everything with hook_order(). Product keys are issued IF the order is transitioning to payment_received OR completed AND the order has no associated product keys.

In theory, this should fix your problem and even the COD problem. Could you test out the dev release dated 3/5/10 or later and see if your problem is fixed (and no new ones cropped up)? Let me know what you find.

Thanks for taking the time to check this out. Your diagnostics are puzzling.

When a key is generated, the email should be sent out. So for the Check method, the key should go out when the payment is received. One question is whether you've ever got the email for any payment method. I use uc_free_payment for testing and I have a test product key with a $0.00 price. I wonder if you could install this module and see if you get the email (unless you have some other way of verifying that the email works). Perhaps you haven't set up the conditional action properly?

The PayPal method reveals some sort of problem—it could be on my side or in the PayPal payment code. It's a pain to test since I have to go set up a sandbox account. I'll check this out when I get some free time. I'm assuming you're not a programmer, but if you are, it should be easy to find the code where the order states are checked and add some debug code to find out why the PayPal payment system is prematurely assigning a product key.

Progress!

In regards to the conditional action, here's the relevant code:

    // Pull the conditional action trigger and send the email to the user with the newly assigned keys.

    if(count($all_keys) > 0) {
      $status = ca_pull_trigger('uc_product_keys_assigned', $all_keys, $user, $order);
    }

In other words, the email is sent only if some product keys are assigned.

In regards to PayPal, what I would do is go to uc_product_keys_order() and add the following debug code:

    $old_state = uc_order_status_data($order->order_status, 'state');
    $new_state = uc_order_status_data($arg2, 'state');
    var_dump($old_state, $new_state);

The var_dump() may screw up the checkout process, so you may want to enable it only right before you submit the order. An alternative is to use something like:

file_put_contents('somefile.txt', "$old_state $new_state\n", FILE_APPEND);

This should reveal whatever may be causing the problem. Before making any changes to the PayPal payment code, you may want to do some research to find out why they do whatever they do. One of the problems with using hook_order is that there are a lot of payment modules and they don't all use the state settings in a consistent manner. It's sometimes impossible to write code that will work with all the payment methods.

Since you're new to Drupal/Ubercart, let me point you to a discussion of order states vs. order statuses: http://www.ubercart.org/docs/developer/920/order_states_and_statuses.

I looked at the PayPal payment module code and I see it adds a status of "paypal_pending" and matches it to state "payment_received". It also (in _uc_paypal_pending_message()) lists a number of reasons way a payment may be pending. In some cases, the payment has actually been received from the customer but requires some additional action before you can received the funds.

So why don't I just check for the "completed" state? Some payment modules don't place the order into the completed state.

To get this right, I would have to code the correct condition check for each payment method. This is not possible, but what I've done is added a hook so that people can customize the condition based on whatever payment system they have. Check the revised README.txt file for hook_uc_product_keys_order_ready(). I only did enough testing to make sure that, if no one implements the hook, the code still issued the keys the same as before.

If you've never extended a hook before, you will need to read about creating a module. The module should be pretty simple. You will need an info file and a module file. The module file will include a function called [module name]_uc_product_keys_order_ready($order, $status). I think you can get the payment system from the $order object. Since you know the payment system, you can use the order statuses added by the PayPal module in addition to looking at the states.

Let me know if you have any success using the hook to resolve your problem.

The reason I don't look at statuses is because of the way they are specified (see http://www.ubercart.org/docs/api/uc_order_status_list):

Statuses may be renamed and reordered, ...

There is no guarantee that any particular status exists in any instance of Ubercart. Your code may work with your system, but I can't incorporate it.

The PayPal module is used by a lot of people, so your code would probably be a nice little extension to have. Why don't you attach your module here and I'll add it as a sub-module that people can enable if they are using the PayPal payment system. I will credit you as the author, although I will make modifications if needed.

Ideally, the module should check if the payment system is PayPal. If not, it should return NULL for the hook. If it is PayPal, then test for the right conditions under which to issue the keys and return TRUE or FALSE. If it's written properly, it shouldn't be specific to your system, just to PayPal. The real trick is that there are several ways PayPal can be used. I forget the names—I know one is called PayPal Standard. The module should work (and be tested) with all these modes. Since you probably just use one type of payment, you'll need to tell me which type you've tested.

If you want to make a more significant contribution, you'll see if you can make your module work for all the ways in which the PayPal module can be set up.

Thanks for testing my changes!

Hi,

I finally had time to check out your module. I made a few minor changes in the formatting and such, but it still uses the exact same algorithm you created. I checked it out as far as making sure that I hadn't introduced any typos and that I could place an order with your module enabled. I didn't actually try to set up the PayPal code.

I've created an RC1 release. If you download this, you will see the changes I made to your code. Also, the RC1 should continue to work for you—holler if I screwed up something.

Be sure to disable your module, remove it from the sites/all/modules folder, install the update and then re-enable my version of your module.