Subscription Cancellation options

This would be a huge amount of work. Currently all the subscription handling is done by PayPal and my module obey's it. So when a user cancels a subscription at PayPal my module obeys the cancel when it arrives. As PayPal sends it straight away that is when the users subscription is cancelled.

To delay the cancellation till the end of the period would involve duplicating PayPal's timers tracking subscriptions (and making sure they keep in step) then cross checking any incoming cancel from PayPal and overriding it where necessary.

Even if I thought it was a good idea, and I'm really not sure it is, this is way more work than I'll have time to do for the foreseeable future.

Lee

I have a requirement of client on this and I wonder if you are willing to let me contribute this part of it to the module? Would you be likely accepting/reviewing such a feature.

I believe is not that much of timing functionality that needs to be replicated, just that bit of allowing the term to finish. It can be something completely handled on-site on the cron hook.

For what I've seen so far I think it's something like setting the cancel subscription to a 'cancel pending' status or something like that and then have cron perform the unsubscription on the site.

As I said, I do have to work on this, so I guess it may be better if I contribute it, what are your thoughts?

Also, worth asking, should I we working on the 2.x version? What's the current status on that version? What are/were the major changes on that branch than the 1.x? Any introduction to it might be helpful if you are willing to allow a new contributor to it.

Looking forward to hearing from you.

It's likely that I'll have to start working on this soon.

6.x-2.x has had significant work on it to start making this module more generally usable, and code cleanups etc, but it got broken by a bad commit many months ago, and hasn't had much attention since then (one maintainer is having a sookie about it, and the other is too busy to fix it).

If you can try 6.x-2.x, maybe you can help iron out the bugs, and make that the official version again. Then that would be the right place to apply new work.

If you submit a working patch, that includes (a) configuration to make this behaviour optional (and non-default), and (b) simpletests - then I don't see any reason why it couldn't be applied.

As you know, we'd want to see "form" on helping with this module before adding new committers, but I see you've got a fair but of ubercart/payments experience.

Thanks for replying. Any hints or pointers into what's broken on 2.x and what was the commit that broke it?

Simpletest.... hmm :) I haven't honestly never worked with them, but I am sure there won't be issues, and it might be a good thing to start.

I'll probalby start this the week of Aug 9th, so as much as we can talk about it before then will certainly help.

I think it's the subscription stuff that's broken, and all the things that depend on it, unfortunately. The simpletests should be a good way to identify what's broken (some are broken tests, but most are broken code). After that, try some manual testing, and create tickets with your findings. Good luck!

@lyricnz: Although I would like to jump in the 2.x dev version, I believe I don't have the time right now to surf through the anticipated problems on the 2.x version, and because I do needed this feature and the 1.x is the stable recommended one I worked on that. The fix is quite independent from the rest of the code, although I changed the settings form and followed the ini() way of init global variables.

Here is a preliminary work for you to review if you want. It's preliminary only because i haven't gone with exhaustive testings, but it's likely that I will make live this changes pretty soon on a site I am working on.

I did also fix a small bug in which a ...STATUS_CANCEL was used and was not defined (...STATUS_CANCELLED was).

A very quick explanation of what this code does:

- Adds a config entry to select how to react to cancel IPNs. (Immediate - default and current -, eot - end of term -)
- Checks for that setting when receiving the cancel IPN and not remove role if set to eot.
- Adds logic to cron to iterate (if config is set to eot) over the cancelled subscriptions and remove roles on the ones that has an overdue term (and set the subscription to DEAD).

Let me know your thoughts and whether you might consider adding this to the 1.x branch.

Thanks,
a.=

Thanks for your work on the patch hanoi, but it doesn't seem to work in my case.

My problem is similar to the issue: I don't want to use recurring payments on the site, but rather notify users that their subscription is due to expire and encourage them to renew by subscribing again.

So I set up a subscription that does not automatically renew but has a term of 1 year. The problem is that PayPal accepts the payment and marks it as expired at the same time. So lm_paypal also sees it as expired and the user isn't granted the role they are supposed to get with the subscription.

I applied the patch in #7 and in Subscription Settings I set the "Cancel behavior" to "End of term."

But when I submit payment to PayPal, I get an immediate cancellation (as expected since it is not a renewing payment and PayPal marks those as expired immediately) but the user is still unsubscribed from the subscription and the role on the site.

Any ideas why this might be happening? I'm new to Drupal coding at this level but I can follow the logic of what you did in the patch and it looks sound to me. Have you tested this successfully yourself?

Thank you,
Christopher

I did with recurring payments and then cancel it on a second step.

The only possibility I can think of is that you are not getting a properly payed IPN message that's why you are not getting the role, but I am just wild guessing.

If I have time, I will try a subscription like yours and see if I notice anything unusual.

Thank you for the thoughts.

The only possibility I can think of is that you are not getting a properly payed IPN message that's why you are not getting the role...

This makes sense actually. I think lm_paypal is relying on PayPal's reporting to track users subscription status (right?), but it seems like PayPal simultaneously subscribes the user and sets the users subscription to "expired." If so, then lm_paypal would never know the user was ever subscribed, as if the user hadn't completed the PayPal transaction.

However, when I spoke with PayPal this morning about this issue, they said that, as far as they were concerned, the subscription is still in effect for the full year. But when I log in to the PayPal account I'm using for testing, the subscription is listed as "Expired" so I don't know where/how PayPal flags the subscription as still in effect.

I don't see how lm_paypal could be modified to account for this situation since it's getting it's information from PayPal and PayPal isn't reporting accurately. Or perhaps there is some hidden setting at PayPal that shows a subscription as "Active" when everywhere else it is shown as "Expired" (?) and which could be accessed by lm_paypal.

Yes, lm_paypal is relying on Paypal's subscription status: lm_paypal doesn't interact with Paypal, other than responding to (and verifying) IPNs.

Following up on this.

I think LM should add an expiration date that takes precedent over Paypal. This way, when a user cancels, the expiration date is still in effect and if the user renews, the expiration date is extended..