The attached patches bring the uc_cim module current with the latest dev releases of ubercart, uc_recurring... file size grew about 8%. Please review.

Some notes.

1. These patches were developed for a site that is being migrated from Authorize.net ARB to CIM services (ARB orders are being phased out). It has been developed mainly with just a subscription site in mind. Some of this code your site could do without.

2. uc_cim.module::uc_cim_check_fee_record() : there's a bug in uc_recurring that sometimes doesn't update the uc_recurring_users.uid to the global $user->uid after an anonymous checkout (uid is set to 0). Also, the order_status should be set to completed if the transaction succeeds (the purchased role isn't granted with payment_status=='payment_received'). This function updates the uid and the payment status, given the right conditions are met. It's called from uc_recurring.module::uc_recurring_fee_user_save(), whenever a new record is inserted into uc_recurring_users. This might be better called elsewhere - I didn't find a hook for uc_recurring_fee_user_save(), to try to save a patch to uc_recurring.module. This function would be moot if uc_recurring were patched to address this bug... this is more of a remedy for the symptom.

3. If the active, purchased role isn't in the user's roles, get_fee_vars() will return an object with some of the expired fee and order data. With this patch, one of its uses is to change the submit button text for the edit/add payment profile forms... on submission, the fee record will get updated to be processed with the next cron.

4. This patch fixes a few of the bugs noted in http://drupal.org/node/915084

These patches, along with some custom coding, work for me. Your mileage may vary.

CommentFileSizeAuthor
#10 uc_cim-update.patch20.67 KBentrigan
uc_recurring.module.patch357 bytesjaypark
uc_cim.module.patch20.86 KBjaypark

Comments

jaypark’s picture

jaypark commented
Assigned: jaypark » Unassigned
torgospizza’s picture

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

Awesome work. Subbing.

mr.andrey’s picture

mr.andrey commented

subscribing

Jackinloadup’s picture

Jackinloadup commented

subscribing

entrigan’s picture

entrigan commented

Hey jaypark, excited to see the work you have done. I know you have been active in a few issues here and on uc_recurring, is this the culmination of those efforts?

Applying patches now, will review.

entrigan’s picture

entrigan commented

Ok, patches applied clean, I set up a test account with authorize.net, and successfully checked out on my dev site.

However I am a bit confused with the uc_recurring integration. It appears cim is not an option at "admin/store/settings/payment/edit/recurring". Consequently while a recurring fee does get set up upon checkout, there is no option for editing the recurrence (under options there is no only a cancel link).

Did I miss something?

entrigan’s picture

entrigan commented
Status: Needs review » Needs work

It looks like the edit operation needs to be defined in hook_recurring_info 

 'menu' => array(
      'cancel' => UC_RECURRING_MENU_DEFAULT,
      'edit' => UC_RECURRING_MENU_DEFAULT,
    ), // Use the default user operation defined in uc_recurring.

Also I noticed you did not namespace a lot of the functions with uc_cim, which could create potential conflicts with other modules.

Going to keep digging into it, and will submit a patch when I have something substantial. Thanks for the hard work jaypark!

jaypark’s picture

jaypark commented

Thanks for your review entrigan. Your patches would be welcome, substantial or not... maybe you'll have more luck getting the maintainer to commit?

jaypark’s picture

jaypark commented

cim is available as a payment method, admin/store/settings/payment/edit/methods

you can have multiple payment methods, each with a recurring handler - whichever one was used to purchase the order with the recurring product will be used to handle the recurring fee.

i'm not sure what you mean by "editing the recurrence" - remember that uc_recurring is a different module. uc_cim lets the customer update (edit) their payment profile(s) with the tab labeled "manage credit cards".

entrigan’s picture

entrigan commented
StatusFileSize
new uc_cim-update.patch20.67 KB

Updated patch.

I added edit functionality to recurring fees (so that admin's can change the date or amount of the recurrence).

I also name spaced a few of the functions with uc_cim_ (although there are more to do).

entrigan’s picture

entrigan commented

I think the remaining issue that prevents this from being RTBC and ready to be pushed to uc_cim is the uc_recurring patch.

EDIT: That and cleanup
EDIT EDIT: Well... also there is the issue of whether or not it is reasonable for the module to depend on uc_recurring.

torgospizza’s picture

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

Why should uc_cim depend on uc_recurring? That doesn't make sense to me. I think you should be able to leverage uc_cim if you are setting up Recurring Fees with the uc_recurring module, but it shouldn't be a requirement.

entrigan’s picture

entrigan commented

I agree, but the issue is that the code here does depend on uc_recurring, and the code currently hosted on the project page is unusable.

I am assuming long term development is going to happen at http://drupal.org/project/uc_authnet

So the question is, do we mark uc_cim as abandoned, do we commit working code that is dependent on uc_recurring, or do we wait for a more complete solution to come (which probably will not happen again, because uc_authnet is more promising).

jaypark’s picture

jaypark commented

i hardcoded the dependency due to delivery time constraint for a live site that uses this patch. if i get some free time or enough folks clamoring for it, i can take another look for proper rewrite. why it's called from uc_recurring is noted in #2 in the op.

edit: the uc_recurring patch is not, strictly speaking, a dependency. uc_cim.info wasn't edited for any dependencies. you can call uc_cim.module::uc_cim_check_fee_record() anywhere you want... that said, i'm not sure where else you'd want to call this function.

noahlively’s picture

noahlively commented

Thanks for this patch.

mr.andrey’s picture

mr.andrey commented

subscribing...

interestingaftermath’s picture

interestingaftermath commented

subscribing

mr.andrey’s picture

mr.andrey commented

Just tested the patches (updated one from #10). Ubercart 2.4, Feb.10 Dev of uc_recurring.

Purchase of recurring product with a new credit card: works.
Purchase of a regular product with a remembered credit card: works.
Renewal of a recurring product: works.

Looks good.

mr.andrey’s picture

mr.andrey commented

There is an issue with customer_payment_profile_id field being set to INT(11). The max possible value for that field is 2147483647. Unfortunately that's not big enough for Authorize.net. On the dev test account my value for that field is higher. Setting the field to BIGINT(20) should make this problem go away, but 2147483647 is still getting sent to Authorize.net. It's either cached somewhere or there's something in the code still setting the limit.

UPDATE: Nevermind, I got the transaction ID and payment profile ID confused. It all works now.

interestingaftermath’s picture

interestingaftermath commented

For some reason, I do not have the option to Cancel or Delete recurring fees. In addition, my customers do not have the option to cancel either. Anyone else have this issue? I've applied the patched and even got the patched uc_cim and uc_recurring modules directly from mr.andrey who has this working on his site.

I'm at a loss.

interestingaftermath’s picture

interestingaftermath commented

I don't know if I should open another issue for this or not but my fear is that it will never get seen as this module seems a bit inactive.

My recurring fees are not charging. In watchdog, uc_recurring says "1 recurring fees processed successfully; 0 failed." and on the order it shows "New recurring fee processed, new order is 324." but order #324 shows Pending with a balance instead of Payment Received and no balance. Also, there is no indication that uc_cim is even being triggered.

I have ordered non-recurring products and the charge goes through just fine. This site is an upgrade from Drupal 5 in which I was using the similar setup of the D5 equivalent of uc_cim and ubercart. Any assistance would be greatly appreciated as the site is live and I'm having to run these charges manually.

entrigan’s picture

entrigan commented

This module is pretty much broken. If you apply the patch from 10, you should have a good starting point for coding your own custom solution, but I would not recommend trying to use this module as a drop in solution.

Alternatively if you have a longer timeframe you could work on getting http://drupal.org/project/uc_authnet working with cim integration.

interestingaftermath’s picture

interestingaftermath commented

Just wanted to update everyone... with the help of Andrey I got it working. I had upgraded from D5 to D6 and some of the tables had differing characteristics, etc. Once we got that all sorted out it's back to working as expected.

I am going to keep an eye on uc_authnet but without an upgrade path to it, I probably won't be able to considering the amount of recurring fees we'll have by then (hopefully!).

Thanks everyone!

mattcasey’s picture

mattcasey commented

sub

m.stenta’s picture

m.stenta
he/him
Primary language English
commented

amorsent and myself have begun an overhaul of this module, starting with a cleanup and reorganization of the code.

As of last night, the patches in this issue will NO LONGER APPLY to the 6.x-1.x branch. They WILL, however, apply to the origin/master branch, which we've left in place for anyone who needs this in the meantime. You will need Git in order to retrieve the origin/master branch.

We will need uc_recurring ourselves, so this issue will be re-approached soon. Stay tuned!

m.stenta’s picture

m.stenta
he/him
Primary language English
commented
Version: 6.x-1.x-dev » 6.x-1.0-alpha1

Update: I created a 6.x-1.0-alpha1 release that contains a snapshot of the code as it was before we started working on it. The patches in this issue should apply cleanly to that. So you don't have to checkout the master branch as I described in #25 above.

6.x-1.x is for new development now, so it may be unstable. If you need a working version of uc_cim, you can try the alpha1 release with the patches here... but I can't vouch for any of it yet. Still digging into all of it...