Make it easier to integrate with LM Paypal

My solution is very poor:
When the user want to pay, I create a SESSION variable with the id of the advert located in the url.
And then in lm_paypal_subscriptions_inprogress()
I lunch an sql query, setting de ad's status "active".
I don't wait for "saved ipns" because I don't receive any messages.... And I don't know why.

I saw your other post http://drupal.org/node/339037.

I only played with the module since yesterday. I have very limited understanding of the module.

If it is to be re-designed, I would recommend rename the donation sub module. The sub module name is sort of misleading, indicating that it is for donation only. I believe the module as-is can be used for some other payment cases (such as paying for a course or buying a book). So I think it would be a good idea to give it a generic name (e.g. lm_paypal_simplepay).

I'm still testing to see if I can make generic payment. I'll report back if I see problems.

my 2 cents.

I just finished my initial test to use the renamed donation module for generic payment. It appears to be working so far. It re-enforces my belief that the "donation" module should be renamed to something like "simplepay".

I have only tested with one single item purchase. I believe in paypal's terminology that means txn_type is "send_money" or "web_accept".

I see paypal has more txn_type's. They are "cart, express_ checkout, merch_pmt, send_money, virtual_ terminal, web_accept". I believe if the sub-module is renamed, it should stick to the two existing txn_type's initially. At least, people can use it for simple one-item purchase payment other than "donation".

my 2 cents.

As we conversed in mails, define a hook to notify lm_paypal based modules should be a good thing.

There also another question which is how to route the right IPN to the right module (should the lm_paypal propose a generic paypal form, with somewhere in data we sent to paypal the module name so we could grab it and notify the right module?).

Or maybe we should let a simple hook do it's job, then all module developpers may just test themselves if this IPN is for them.

It would be great to be able to trigger an action when a user subscription ends.

For what's related to roles subscriptions, my understanding is that, by now, LM_Paypal just removes the user role that was assigned at subscription time.

Then it becomes difficult to differenciate users "returning form subscription role" from users who "never subscribed".

So having rule like: "user returning from subscritpion #1" would be great so we can easilly trigger "external actions" that belongs to unsubscription process.

A lightweight approach could be to grant the possibility to define a "destination rôle" for unsubscribed users, on per subscription basis.

I personnally use this, so I can trigger actions when a user is unsubscribed.

- I defined a specific role (only used to manage user transition).
- I use it to trigger a rule .
- Then this rule enables actions that sets the appropriate role for the user + some other actions on user contents.

For the time beeing, it a "one line harcoded hack" that assigns my "transitory role" to the user, just before subscribers role is removed in function lm_paypal_user_role().

lyrincz: Regarding Workflow NG that is deprecated as of Drupal 6 in favor of Rules, which is an advanced implementation of Workflow NG and triggers.

On the Rules page (http://drupal.org/project/rules) the author explains there is an API for Rules "Modules may use the rules module's API to provide new events, conditions, actions, rule sets as well as default rules, which can be customized by users. Users can share their customizations by using the built-in import/export feature."

I believe the best way would be to look at how existing modules do these kinds of things. I for one thing know that User Points has a massive amount of integration with other modules, perhaps that could be used as a footprint. :)

Depending on contrib module is dangerous when similar feature (even with less power) exists in core. A lot of factors make such choice difficult:

• First one is, if no maintener of our own module uses those module, integration won't be right;
• If contrib module (dependency) is not well-maintened, it will result that our module will be unstable;
• What are the real features our users want, does the core feature isn't enough for them?
• We have today a long todolist with lm_paypal core, is this integration valuable while our own module still not stable?

It was today's though.

Totally agree.

I'm not Hijacking the issue.
Enabling recurring paiements is a typical feature for wich LM_Paypal as a strong added value.

And enabling recurring paiements is most often an integration issue, as you need to perform additional actions that grants new features to subscibed users.
For recurring paiements to be completely implemented, we also need to manage users who stops their subscription.

This is the link to your issue, as per today, we need to hack the code to differenciate people who stopped their subscription, from people who never subscribed.

My proposal was that LM_Paypal could expose a rule in that case (people returning from subscription) so we can implement actions without impacting LM_paypal.

Depending on the complexity of exposing that rule, I pointed another alternative, (based on roles) that could ease LM_Paypal integration. With such a feature, we could reuse an existing rule to trigger the additionnal actions we need.

Thus, you could provide an integration feature without impacting the logic of your module.

I believe this is also in line with other comments, as you wouldn't have to rely on other modules to maintain that feature.

Br,
Erco

That's a point.

I think we'll come to think about this when the 6--2 version will become stable, at least I won't do anything before myself.
Trigger support should be implemented by each submodule, in a non dependent way.

I would love to see the Rules integration. But even more importantly would be for Views integration.

Integrations with Rules and Views would be of interest to my clients. I currently have their site send and email when a visitor starts a donation on our site, but I don't have an automated way to show them the donation has been completed. Paypal can send a email, but I would prefer to incorporate into my application. I also provide them with panels based dashboard that shows activity on the site and would like to be able to include data from the IPNs. I think this would require views...

edit: right now I just provide a link in the dashboard to the saved IPN page.

Thanks!

Lyricnz

Absolutely. With Drupal 6 LM_Paypal seems to have a monopoly on Paypal integration IF you don't want to go down the route of one of the ecommerce suites. Making it more "integratable" would be fantastic and IMHO firing triggers would be the simplest way to open the module up.

I can see from the notes that you have started down this route with the 6.x-2.x-dev release and want to offer my encouragement ( for what it's worth ! ).

Now I'm going to download alpha-1 and see if I can understand what's occuring.

Keep up the great work.

Dave

I think Rules and (then) Views integration would be essential. I'm trying to fire a rules trigger as we speak.

My suggestion is that Views should be the priority. Mainly for Subscriptions, so the nodes could be filtered by their subscription status.

While I would welcome any integration with Views or Actions, I think bringing the hook system in LM_Paypal in line with the Drupal standard would be a priority for me. I'm having a great deal of difficulty hooking into LM_Paypal's IPN processing system. There's a lot of complexity surrounding ini functions, register functions and the complete lack of documentation of how one would write a module to leverage LM_Paypal for such.

Subscribing.

It would be useful to put a definition of the $ipn object into the comments, to give some indication of what to do when writing a hook_lm_paypal_ipn.

i agree with erco: "we also need to manage users who stops their subscription".

what i would like to see is simple. in a subscription, i'm allowed to override the default "thank-you" page. when a subscriber goes to paypal to cancel their subscription, a subscr_cancel ipn is sent back to my site. based on the logs, it seems to go to a page, example.com/lm_paypal/ipn. i would like to be able to override that page like i can the thank-you page, so that i can clean up the data i was keeping about the subscriber automatically. i don't see a need to the trigger module and all that, just let me substitute my own page for the default upon cancellation.

Views integration now has its own issue #1102400: Views integration

Subscribing...

Rules intergration would make the module far more powerful... The project I am working on is in dire need of such a mechanism. Has anyone hacked in Rules integration yet (and willing to share??)