Author Topic: Passing additional parameters to payment processor back ends (Read 9607 times)

Donald Lobo · August 27, 2009, 06:21:03 pm

lets chat and resolve this on IRC.

lobo

dmccarney · August 31, 2009, 11:45:35 am

I've tried implementing torenware's patch. Unfortunately it doesn't seem to be helpful for me.

I'm looking to include additional information in the $params argument. Information that is never passed to the payment module and is thus not available to the hook.

Donald: You said that the information from the form post is still in the $_SESSION. Is there an easy way for me to pull this information out? I've dumped the $_SESSION structure as seen from within the _civicrm_paymentProcessor hook and the structure is very confusing.... If I could find out how to get the item subtotal details for the transactions (price, quantity, name) out of the $_SESSION var then I could use the paymentProcessor hook to embed that info into the cooked params. This should make my mod to Moneris.php a little less intrusive...

Thanks!

- Dan

Donald Lobo · August 31, 2009, 11:55:43 am

i would suggest the following changes to torenware's patch to get the best of both worlds:

1. send in the form object to doDirectPayment

2. doDirectPayment in turn sends it to the hook (which then has a lot of additional information)

this is a pretty big change to quite a few functions and we'd be hestitant to add it to 3.0. I think we can add it to a later 3.0 release

the form object session structure is much simpler and gives you better access/functions

torenware: do u agree, and if so, u think you can submit a patch that fixes ALL the payment processors?

lobo

dmccarney · August 31, 2009, 12:25:56 pm

Quote from: Donald Lobo on August 31, 2009, 11:55:43 am

<snipped>
1. send in the form object to doDirectPayment
<snipped>

Dumb question, but is there a central location that does the doDirectPayment call?

- Dan

torenware · August 31, 2009, 12:58:37 pm

I believe there is. Just grep the sources for it; it's somewhere in CRM/Contribute/.

torenware · August 31, 2009, 01:13:22 pm

Lobo,

On a bit of reflection, here's a simpler way to do what you're suggesting. Don't change the hook at all: just change the base class of the Processor class, and add a setter and a getter for the form object.

The object is not around very long in any case, and it makes it very simple to add the form object before calling doDirectPayment(), and it makes it very simple for somebody needing the form arguments to get at them.

I can add this to my 3.0 patch if you like.

dmccarney · August 31, 2009, 01:30:51 pm

Quote from: torenware on August 31, 2009, 01:13:22 pm

Lobo,

On a bit of reflection, here's a simpler way to do what you're suggesting. Don't change the hook at all: just change the base class of the Processor class, and add a setter and a getter for the form object.

I'm no expert, but it looks like we could add something like:

Code: [Select]

           
 $payment =& CRM_Core_Payment::singleton( $this->_mode, 'Contribute', $this->_paymentProcessor );
 $payment->setForm($this); //New line          
 $result =& $payment->doDirectPayment( $paymentParams );

to CRM/Contribute/Form/Contribution.php, around line 883. (Assuming that the Processor class is modified to have that setForm accessor).

- Dan

Donald Lobo · August 31, 2009, 01:47:54 pm

i think we can accomplish this quite easily (w/o changing the interface or a lot of code by):

1. add the $form parameter to all places which calls: CRM_Core_Payment::singleton

2. extend CRM/Core/Payment.php to hold the $form as a reference variable, and add a setter/getter to it. All processsors should be extending this class.

3. change the singleton function to set the form variable

4. change the hook to also send the form variable by reference

lobo

torenware · August 31, 2009, 01:57:52 pm

Sounds simple enough to me.

You going to add that to #4969, or do you want me or dmccarney to do it against the 3.0 tree?

Donald Lobo · August 31, 2009, 02:07:31 pm

can u resubmit the patch please. You should grep for all the files that use: CRM_Core_Payment::singleton

if u can submit a patch against the trunk svn that would be great

thanx

lobo

torenware · August 31, 2009, 02:14:31 pm

Will do. Will likely have it later today.

dmccarney · August 31, 2009, 02:21:57 pm

Quote from: torenware on August 31, 2009, 02:14:31 pm

Will do. Will likely have it later today.

Would you mind posting here with a link? Or is there an easy way to watch the Jira tracker?

torenware · August 31, 2009, 03:12:25 pm

Yeah, there is. Get yourself an account on JIRA, and watch the bug. Should work fine.

I'm patching 3.0 (the trunk, actually), which due to some reformatting of some of the files in the 3.0 tree likely won't patch 2.2 correctly. But it will be easy enough to see what I did. I don't think the processor related code has changed in any substantial way in any case.

dmccarney · August 31, 2009, 03:26:23 pm

Quote from: torenware on August 31, 2009, 03:12:25 pm

Yeah, there is. Get yourself an account on JIRA, and watch the bug. Should work fine.

I'm patching 3.0 (the trunk, actually), which due to some reformatting of some of the files in the 3.0 tree likely won't patch 2.2 correctly. But it will be easy enough to see what I did. I don't think the processor related code has changed in any substantial way in any case.

Great

I've got a Jira account now. I agree, I should be able to backport your patch to 2.2 without too much trouble.

Thanks again! I appreciate the work you've done for this.

torenware · August 31, 2009, 04:37:27 pm

Lobo,

One issue with using the ::singleton() method to do this: it's declared static, and there isn't any reasonable place to stash the $form argument.

The implementation for CRM_Core_Payment::singleton goes on to call a singleton method in the appropriate implementation class, and actually returns the subclassed singleton object. So we'd need to munge these methods as well, and even there, we'd have the same class vs. object issues at that level.

I suspect it's simpler to add the code to the hook definition, and remove some of its redundant params to make room for them (since you currently have a limit of 5 args to your hooks, due to the way CRM_Utils_Hook::invoke() does its work.

What say you on this?

CiviCRM Community Forums (archive)

News:

Author Topic: Passing additional parameters to payment processor back ends (Read 9607 times)

Donald Lobo

Re: Passing additional parameters to payment processor back ends

dmccarney

Re: Passing additional parameters to payment processor back ends

Donald Lobo

Re: Passing additional parameters to payment processor back ends

dmccarney

Re: Passing additional parameters to payment processor back ends

torenware

Re: Passing additional parameters to payment processor back ends

torenware

Re: Passing additional parameters to payment processor back ends

dmccarney

Re: Passing additional parameters to payment processor back ends

Donald Lobo

Re: Passing additional parameters to payment processor back ends

torenware

Re: Passing additional parameters to payment processor back ends

Donald Lobo

Re: Passing additional parameters to payment processor back ends

torenware

Re: Passing additional parameters to payment processor back ends

dmccarney

Re: Passing additional parameters to payment processor back ends

torenware

Re: Passing additional parameters to payment processor back ends

dmccarney

Re: Passing additional parameters to payment processor back ends

torenware

Re: Passing additional parameters to payment processor back ends