hook_user_cancel() integration.

Yes, handling this and also giving the user the ability to cancel their account is on the to-do list.
Happy to hear suggestions.
My thinking was emptying the next payment date on the recurring order and the next due date on the master order.

Lee

Seems to me this should be possible via a combination of Rules and user Roles.

I imagine something like this:

1 - a user purchases a subscription and they are assigned to the "subscriber" role.
2 - a condition to check if a user has the "subscriber" role is added to the "Generate Recurring Order if Appropriate" component rule.
3 - if the user has the role, the recurring order is created, if they don't it isn't.

So here's what would need to be done to make this work:

1 - add the "user" data type to the "Generate Recurring Order if Appropriate" component rule
2 - Need to setup a new rule that removes a user from the "subscription" role IF they choose to cancel their subscription. Via a link on the user page or an email request to the admin, etc.

Additional idea:

It would also be nice to have something like an "recurring active" toggle switch on the master order. That way we could setup the conditions to check for the user role AND the "active" setting on the order before generating new recurring orders. I imagine this as a fail-safe in the event that the user isn't removed from the "subscriber" role upon cancel.

I'm going to be investigating the module more over the next couple of weeks (trying to integrate it with Stripe), so I'll post any additional ideas / patches I come up with. And of course I'd love to hear if anyone else has thoughts on this.

Brad

Has anyone made progress with this issue?

At this point there are 6 sites using the 1.x branch of recurring framework, I'm dropping support for that version recommending to use and contribute to the 2.x