Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dev/financial#33 Add in Hook postIPNProcess to allow Extensions to do c… #12928

Merged
merged 1 commit into from
Oct 25, 2018

Conversation

seamuslee001
Copy link
Contributor

…ustom processing of the IPN Data

Overview

This adds in a hook alterIPNData which would allow extension authors the ability to do custom processing on IPNs as they come in

Before

No Hook on the IPN data

After

Hook exists, meaning custom processing such as sending google analytics information based on the IPN data can occur

ping @eileenmcnaughton @monishdeb @johntwyman

@civibot
Copy link

civibot bot commented Oct 12, 2018

(Standard links)

@civibot civibot bot added the master label Oct 12, 2018
@eileenmcnaughton
Copy link
Contributor

@seamuslee001 we have some tests for alterPaymentProcessorParams in our suite - can we get a similar one for this

@pradpnayak
Copy link
Contributor

Thanks @seamuslee001 for the new hook implementation. I have extension that does need to perform some validation and alter to ipn's $_REQUEST before they are processed. I used config hook as an alternate method but alterIPNData seems to be most generic.

@seamuslee001
Copy link
Contributor Author

@eileenmcnaughton i have added in a unit test now

* @param array $IPNData - Array of IPN Data
* @return mixed
*/
public static function alterIPNData($IPNData) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@seamuslee001 did you missed & here or there is a reason you don't want to pass by reference?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At dev/financial/issues/33, @seamuslee001 writes

We could also ensure that the original data not get modified by not passing by reference so that the hook could only do its own processing without affecting the original data

The intention needs to be clarified.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes sense to pass by reference - a hook should be able to alter

@monishdeb
Copy link
Member

@seamuslee001 Except for that minor change I mentioned on the patch, can you please submit a doc PR? against https://github.com/civicrm/civicrm-dev-docs

@@ -745,6 +745,7 @@ public function cancelSubscription(&$message = '', $params = array()) {
*/
static public function handlePaymentNotification() {
$params = array_merge($_GET, $_REQUEST);
CRM_Utils_Hook::alterIPNData($_REQUEST);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you need to pass $params here not $_REQUEST

/**
* Store Custom data passed in from the PayPalIPN in a custom field
*/
public function HookCiviCRMAlterIPNData($data) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

trivial point - lower case h I think

@@ -38,6 +38,7 @@

require_once '../civicrm.config.php';
$config = CRM_Core_Config::singleton();
CRM_Utils_Hook::alterIPNData($_REQUEST);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should add hooks into these deprecated paths - there is some risk of them not working from previous nightmares with these bits of code so I'd rather not touch (also people should stop using them)

extern/ipn.php Outdated
@@ -41,6 +41,7 @@
/* Cache the real UF, override it with the SOAP environment */

$config = CRM_Core_Config::singleton();
CRM_Utils_Hook::alterIPNData($_REQUEST);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also deprecated path

extern/pxIPN.php Outdated
@@ -19,6 +19,7 @@
require_once 'CRM/Core/Config.php';

$config = CRM_Core_Config::singleton();
CRM_Utils_Hook::alterIPNData($_REQUEST);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

def deprecated - hopefully this processor is disabled on install

@eileenmcnaughton
Copy link
Contributor

@seamuslee001 @mattwire I think we can call this hook (once only) from

CRM_Core_Payment::handlePaymentMethod (somewhere after logPayment) - all the new style ipns hit that.

It would be a little trickier for unit testing - but not unresolvable I'm sure

@seamuslee001
Copy link
Contributor Author

@eileenmcnaughton @mattwire i have made the changes as has been requested, I have also managed to get the unit test updated for handlePaymentMethod. I have put the hook after the main processing so that there isn't any chance of issues being caused from the hook preventing normal processing of the IPN

@seamuslee001 seamuslee001 force-pushed the dev_financial_33 branch 2 times, most recently from 6c6b5e4 to 8fac610 Compare October 16, 2018 08:56
@eileenmcnaughton
Copy link
Contributor

@seamuslee001 so just working through this - it's not really an alterIPNData hook is it - it's basically a listener / post hook

@seamuslee001
Copy link
Contributor Author

seamuslee001 commented Oct 18, 2018 via email

@eileenmcnaughton
Copy link
Contributor

@seamuslee001 should we rename it then? If the logNotification method called a hook then it would achieve the same thing but it doesn't from the looks

@seamuslee001
Copy link
Contributor Author

seamuslee001 commented Oct 18, 2018 via email

@eileenmcnaughton
Copy link
Contributor

@seamuslee001 yeah I think that makes sense - we aren't altering the ipn data from what I can see - although we may take a data related action in the hook. I added a comment on gitlab - I think we should give people a chance to process that

…ustom processing of the IPN Data

Add in unit test of alterIPNData hook and ensure that it is called in all styles of IPN Notifications

Shift hook call to be done in handlePaymentMethod function as per Eileen's comment and remove the hook from deprecated pathways and passbyrefeence in hook

Change name to be postIPNProcess to be more explicit about the purpose of the hook
@seamuslee001
Copy link
Contributor Author

@eileenmcnaughton i have now updated the name of the hook (i'll change the PR title as well shortly) however i think we are now pretty much there right?

@seamuslee001 seamuslee001 changed the title dev/financial#33 Add in Hook alterIPNData to allow Extensions to do c… dev/financial#33 Add in Hook postIPNProcess to allow Extensions to do c… Oct 18, 2018
@seamuslee001 seamuslee001 added the sig:extension support Supports being able to integrate extensions with CiviCRM label Oct 19, 2018
@seamuslee001
Copy link
Contributor Author

Jenkins re test this please

@mattwire
Copy link
Contributor

@seamuslee001 I know I'm late to that party on this one.... Agree with it being called postIPNProcess as it's not allowing anything to be altered. However, some IPN classes don't return, they call exit() instead (eg. paymentExpressIPN call exit on bad parameters) - there are also a number of extensions that call exit() in their IPNs for various reasons.

So I wonder if it makes sense to actually call the hook before processing the IPN, though we'd need to be sure any hook didn't block (as, for example, Sagepay requires a response to the IPN request within 1 second). On the other hand we are logging the IPN to systemlog anyway.. I'm just seeing an extension in my head that passes the IPN to another system or something (eg. an accounting system) which might be interested in that IPN even if CiviCRM fails to process it.

@seamuslee001
Copy link
Contributor Author

@mattwire i think that should be the concern of another hook or at the very least an expansion of hook in terms of when it is processed. I think there could be opportunities to improve this but I don't think it should hold this up @eileenmcnaughton this PR has now been waiting for about a week since we made the change to the name, i note that i don't think anyone in the lab has objected to this and i'm not seeing Matt's comment as a blocker to this PR being merged thoughts?

@eileenmcnaughton
Copy link
Contributor

@seamuslee001 OK - I'll merge this - it will not be 100% reliable for the reason @mattwire mentions & I think calling a pre-hook when we log to the system log makes sense - but I think this also solves a need & should not add a mtce burden due to the tes

@eileenmcnaughton eileenmcnaughton merged commit 65fe53a into civicrm:master Oct 25, 2018
@eileenmcnaughton eileenmcnaughton deleted the dev_financial_33 branch October 25, 2018 00:12
@eileenmcnaughton
Copy link
Contributor

@seamuslee001 can you address documentation for this - I just closed the issue

@seamuslee001
Copy link
Contributor Author

@eileenmcnaughton yep about to work on it now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
master sig:extension support Supports being able to integrate extensions with CiviCRM
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants