Workflow_ng integration: Allows other modules to interact with IPN response and donation record

actually, it looks like this can be achieved by using a hook_form_alter in another module to reset "notify_url" when $form_id == 'donation_form_build'

I've been working on making the paypal IPN response work with workflow_ng. So far I have tokens for all the information in the donations table and an "email donor" action for workflow_ng. I'll happily submit a patch if there is any interest.

The current (proposed) solution does not create an additional dependencies as the workflow_ng action is only triggered when the required modules (token and workflow_ng) are installed and enabled.

If we do this, then be aware that for Drupal 6.x workflow-ng is replaced by the rules module, and hence some work would be involved.

If you are willing to port it when a D6 version comes up, then go ahead and submit a patch.

But before we do that, there is another approach that I think we should consider: is a hook_simplepaypal_ipn() that is implemented by a module_invoke_all('simplepaypal_ipn', $arg_array()). This way it is not restricted to workflow-ng/rules, and is programmatically extensible.

kbahey:

The workflow_ng peice is done already, but I tend to favor the custom hook implementation. Do you have any thoughts on how you would like that to work? Is there anywhere else that it would be nice to have access to the donation data?

This boarders on a different discussion, but I would like to have the option to collect more information on the donation form and have a chance to insert it prior to sending the transaction to paypal. Do you think that can be done with something like drupal_http_request?

The workflow_ng peice is done already, but I tend to favor the custom hook implementation. Do you have any thoughts on how you would like that to work? Is there anywhere else that it would be nice to have access to the donation data?

Here is my thinking to start a wider discussion.

1. In the simple_paypal module, we have a hook_simple_paypal_ipn(). This means the function donation_ipn() will be be renamed to donation_simple_paypal_ipn(), and we have a new function in simple_paypal.module called simple_paypal_ipn() that does a module_invoke_all('simple_paypal_ipn', ...).

2. Other modules using simple_paypal can use that hook as well

3. Modules using simple_paypal can pass in a module parameter (a hidden form element), so modules can ignore IPN from other modules. Perhaps this can be stuck in the 'custom' element together with the uid as a serialized array.

4. workflow-ng and/or rules can be implemented to use those hooks. This means we serve both audiences equally (API users, and end users).

This boarders on a different discussion, but I would like to have the option to collect more information on the donation form and have a chance to insert it prior to sending the transaction to paypal. Do you think that can be done with something like drupal_http_request?

Normally, you can use form_alter to do that, and then use the submit to do a database update. However, things are tricky in paypal forms since they POST to an external URL (see donation_build_form() and how it sets #action.

So, I don't have a ready answer for this. Perhaps we can have a normal (internal) submit handler that does the database write, then does a drupal_execute() for Paypal?

I like the approach that you outlined above. Can you think of any other variables that would be valuable to pass to the IPN hook .. that is, other than the POST array from PayPal?

Also, what do you think about generating a "hash" or transaction id when the payment form is rendered then passing the hash to PayPal as a custom value rather than a serialized array. This way, virtually anything could be stored in a table without having to worry about the length of the "custom" value.

This could be accomplished by calling a single function inside a form building function...

Here is an idea regarding the hash: perhaps a better approach is a simple table with an autoincrement field as the key, a module column, and a text field for the data. This would be serialized data that only the module would understand. So simple_paypal need not know what is being passed. Only that it needs to be passed. Since the autoincrement field will always have a unique value, there is no need to generate a hash.

Ok, sounds like we're on the same page with this. How do you propose rolling it out? I guess I'll just roll a patch against the dev branch.