Allow users to subscribe to a single plan multiple times

I've found previously created request for this: #2025995: Change Quantity Module

I have to re-open this one, because the subject matter of the other issue is different anyway. The other issue is about changing the number of order items (second paragraph of the initial report above), while this one is about inability to place new orders for the same products.

The current state which doesn't allow to subscribe to the items which had previously been ordered covers only some use cases when they sell one line recurring subscriptions with upgrade or downgrade options only.

However, consider a company that sells recurring services of different types and its customers should be able to subscribe for the same type of services multiple times. For example, a web-hosting company sells several types of plans. First, its customer subscribes to one of the plans to host her website. Later she decided to host another website and she wants it to have its own isolated hosting account of the exactly the same type. And she won't be able to do so if Recurly module with current state is used.

So I strongly believe that anything pertaining to previously placed orders (actions like upgrade/downgrade/change number of subscribed items) should be dealt on the user/%/subscription/list page. None of the previously placed orders should anyhow effect and limit future orders, so all products on the user/%/subscription/signup page should be always available. Thus then all possible use cases will be covered.

And here is a simple patch that removes the following part from the includes/recurly.pages.inc b/includes/recurly.pages.inc file.

 // If we have a pending subscription, make that its shown as selected rather
    // than the current active subscription. This should allow users to switch
    // back to a previous plan after making a pending switch to another one.
    foreach ($subscriptions as $subscription) {
      if (!empty($subscription->pending_subscription)) {
        if ($subscription->pending_subscription->plan->plan_code === $plan_code) {
          $variables['filtered_plans'][$plan_code]['selected'] = TRUE;
        }
      }
      elseif ($subscription->plan->plan_code === $plan_code) {
        $variables['filtered_plans'][$plan_code]['selected'] = FALSE;
      }
    }

That part was really unnecessary as, again, everything pertaining existing orders should be dealt on their own pages and should not effect new orders.

Sorry, but previous patch was not clean, please review this one.

Well, I did throughly test the functionality on UI and everything works as expected. I didn't explore code-wise assuming that active subscriptions and all the possible actions with active subscriptions still hold for our use case. The removed part just prevents to subscribe for the same plan on UI level and nothing more. So the rest of the code which concerns any change for the active subscriptions must be kept.

I understand there are use cases for the current state, when there should be no more subscriptions for the same product/plan, however:

(1) I firmly believe those are really rare cases and that the number of commerce projects that need to provide unlimited subscriptions significantly prevail;

(2) it is quite logical and intuitive for most use cases to operate active subscriptions without effecting the future subscriptions. I mean active subscriptions should be upgraded/downgraded/changed/modified on their own pages to which users could go from the page that lists active subscriptions.

Just think: you already have subscriptions, so they are already in the system and should be dealt behind the curtain - both admins and users have their profile account to operate with active subscriptions on "back-end" side. At the same time subscription page is kind of "front-end" for both new and existing users, because they want to subscribe for the new services on this page. And it is really strange to apply any kind of limitations on the subscription page.

(3) However if both (1) and (2) are not convincing to you then let's add another options on the admin/config/services/recurly page next to:

 Single-plan mode
 Multiple-plan mode

options. Though it is already confusing, because I thought that the current state should be covered by first options "Single-plan mode" and the use case that I am trying to get implemented here - by the second option " Multiple-plan mode". Unfortunately, it is not - despite the following description:

Single-plan mode allows users are only one subscription at a time, preventing them from having multiple plans active at the same time. If users are allowed to sign up for more than one subscription, use Multiple-plan mode.

selecting the second option does not unblock the plans to which a user had already been subscribed, so if s/he wants to get exactly the same product again, then s/he simply have no such option.

So if you believe the above two options are valid and each of them is working as expected, then here is my request to add a third option - not to limit anything on the subscription page.

I don't doubt that there are many use cases where this is needed. I would encourage you to not assume too much about use cases you personally have not encountered.

That's true and I just believe that the most cases should be set by default and the less frequently used cases should be available as options. In that sense the stats play some role.

I think at the very least we need to create this as a configuration option that can be enabled. Users currently using this module should not suddenly have their functionality changed without opting in.

Totally agree with you.

How about this one, which adds a new mode option on admin page and preserves checks for two existing modes?

Please note that the includes/recurly.admin.inc had the reversed ordering for mode selection like this:

      '1' => t('Single-plan mode'),
      '0' => t('Multiple-plan mode'),

and since I didn't want to impose the new mode putting it on top (that's for the module maintainers to consider) I had to add it like this:

      '1' => t('Single-plan mode'),
      '0' => t('Multiple-plan mode'),
      '2' => t('Multiple-subscriptions mode'),

So everything works just as before and the only difference is that if the new mode selected then the subscription page makes all plans always available.

Sorry for the wrong patch, please review this one.

It's a shame I totally missed another place where changes needed to be done. To say frankly these are my ever first patches, so please bear with me.

Here is another patch and this time I tested really well putting the site into different modes and everything works as expected.

I see what you mean. I will see if I can make needed changes.

I wanted to work a bit on this today and have decoupled the new options into its own setting in recurly.admin.inc file like so:

  $form['pages']['recurly_subscription_multiple'] = array(
    '#title' => t('Multiple subscriptions'),
    '#type' => 'checkbox',
    '#default_value' => variable_get('recurly_subscription_multiple', '1'),
    '#description' => t('If users are allowed to subscribe to a single plan multiple times, use Multiple-subscriptions mode.'),
    '#states' => $pages_enabled,
  );

And to refactor the template_preprocess_recurly_subscription_plan_select() I wanted to use:

 if (variable_get('recurly_subscription_multiple', '0')) {
   do something;
 } else {  do something; }

but am hitting the wall with what function's logic must be.

You see any of the Single-plan mode or Multiple-plan mode is limiting the https://domain.com/user/%/subscription/signup page and with any of them Multiple subscriptions for the same plan wont' work. So we have to exclude both of them for the Multiple subscriptions to be able to work.

To conclude, the initial proposal is working just as expected, but please enlighten me here if you want this work otherwise.