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.

hackmetal: (Sorry if I was unclear) Please don't use this particular issue for support questions - I am trying to solicit feedback on how LM Paypal should be designed moving forwards. Leave that in your original issue at #328580: the inprogress page

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().

Erco: please don't hijack the issue.

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.

I think that we should provide basic support for firing Triggers, but not rely on it within the module itself (where we should use hooks).

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!