Limited buy option

[shnela]

Now user can buy as many pricing in advance as he wants.
Preventing user from buying more than one pricing ahead seems as good idea.

[cdvv7788]

This is open for discussion, however I think:

• Plans are recurrent. Buying more than one at a time allows users to spend less time doing so. Unless we implement an integration with recurrent charges to credit cards, I don't see any advantage of taking that away.
• When should be a good time to pay if only one period is possible at a given time? 5 days before expiring? after expiration? It opens up a lot of use cases, which may be complicated to cover without much to gain.

[rdlabspl]

• Allowing user to buying subscription for several years in advance doesn't seem like a good idea. We want to have possibility to change plans without worrying that we will have to support some deprecated plans for very long time.
• Here shouldn't be any problems with administrators which will want to allow their users to buy unlimited number of plan pricings in advance, because this option should be configured.
• I think that good strategy is blocking pricings that are shorter that user's days left.
  E.g. when we have plan with three pricing options: 30, 60 and 90 days. And user's account will expire in 60 days, he will be able to buy additional 60 or 90 days, but won't be able to buy 30days.

I've already implemented such option in my project. And can make pull request.

[cdvv7788]

@rdlabspl The logic is confusing. We could forbid the user payment for plans that are beyond their current plan (1.5x to 2x). I.e. User bought a 30 days subscription, and wants to buy 90 more in advance...this should not be allowed, I agree. However allowing only the longer ones? I assume you want that because longer means upgrading.
I think that a good way to handle this is to calculate the remaining time the user had on every plan (after conversions). Upgrades should always be allowed, downgrades should be limited depending on this. The operation of payment and downgrading should be limited by the calculation and if it breaks beyond our limit.
For example...user paid a 30 days subscription, but we don't want them to pay beyond 1.5 (in this case, 45 days). An attempt to do that will be rejected. The only thing he can do, is to upgrade his plan. He upgrades to, let's say, a 60 days plan, and now he has 60+ days available, but he won't be able to downgrade or buy another one of those. He can however keep upgrading his plan.
What do you think @rdlabspl @sebastian-code

[sebastian-code]

This is hard to grasp, because you are all talking about user cases, but at the same time all of you are trying to define your use case as the main/only user case for the package, but I guess we can agree with a few things:

Buying several subscriptions in advance is not a really good idea for the service provider and in this I do agree with @rdlabspl, but you're not thinking than it can make sense for the buyer, who perhaps will take the benefits. Something to solve here.
I still don't see why I should be unable to buy smaller plans that the time I have left, why I shouldn't be able to buy just the 30 days I need.

At a first glance what I can see is a broken workflow which needs to be taken care of.

[rdlabspl]

@cdvv7788, @sebastian-code you're right. Preventing user from buying shorter Pricings when the longer ones are still available doesn't make much sense, but still some kind of limiting endless buying is necessary.
So I propose other, simpler solution to this problem. There should be variable in settings which tells how long user's days_left period can be. If this variable isn't specified, user can buy unlimited number of pricings.

[cdvv7788]

So, before buying we calculate if the time the user would have after buying the plan is bigger than the variable to decide if we let him or not?
Sounds simple and flexible to me. Any suggestions @sebastian-code ?