Support for a free plan

[django-getpaid]

Support for a free plan

[cypreess]

Yes, freemium plan is very needed.

From the perspective of current django-plans architecture please consider following django models:

• Plan model - here we keep basic information on a plan (basically a name, and if the plan is visible/available)
• PlanPricing model - we keep here information how expensive is to buy X days of service within this plan
• UserPlan - we keep here information about what plan is currently active on user account and when it expires.

So from this perspective of a free plan does not really diverse from any other plan. In fact this should be just a single Plan which DOES NOT have any PlanPricing definded (so in fact user cannot buy it directly, there will be no "buy" buttons generated for this plan).

The only difference in the business logic you should implement is to be sure that:

• user is able to change a plan to the plan without PlanPricing (right now this will possibly raise some exception in calculating plan switching price)
• when user changes a plan to the "free plan" (a plan without planpricing objects) his UserPlan.expire will be set None
• when UserPlan.expire == None, rest of the system must works properly (e.g. all logic for expiring accounts and sending expiration notice e-mails) - possibly this should already work without a problem, but who knows ;-)

In terms of presentation layer, there is a question how to specially mark in a HTML pricing table that this plan is freemium? I would suggest to implement plans tagging as described here: #22

When you need something like that, you can just tag the plan with "freemium" tag and use it in you layout.

PS. I would also recommend not to provide a strict rule that there can be only one "freemium" plan. I can imagine that somebody would like to change freemium plan but leaving old clients with old usage quoatas (on the old freemium plan). This would lead to creating a "new" freemium plan, and setting old freemium plan as not available any more. Old users could use it, new one see only new freemium plan, but you end up with 2 freemium plans in the system :-)

[dulacp]

I will use the logic you've described that's a great way to handle that. And I'll fix and turn this issue into a PR with the necessary changes to avoid exception. Be back soon with some enhancements.

And you're right, no constrain on the number of free plan, that was a bad idea.

[brentc]

Did anything come of this?

[andr0s]

+1 here - the free plan is a really important thing!

[brentc]

So I've implemented most of the suggestions here for implementing a free plan. But I've run into an issue with the way the system implements plan changes.

When downgrading from a paid to a free plan, I'm setting UserPlan.expire to None, but when upgrading from a free plan to a different plan there's no good way to set the plan expiry because there is no pricing chosen during plan change, just the new target plan.

Was there a reason for this lock of explicit pricing choice during plan change?

[brentc]

Perhaps if the user's current plan is one of these "free" plans, we shouldn't allow a standard plan-change, but rather force a normal plan-order.

[cypreess]

I think the most reasonable thing is to force user to purchase a paid plan in this case. The other way is maybe implementing some settings variable that says if user has free plan he can change plan and get X days for free , than he starts to pay. But It is rather a questiom does the second sollution have any business application. I would prefer first solution as it is elegant and obvious. You have free plan until you finally pay for some extra plan.

[brentc]

I have a PR that implements the first option (I believe) incoming...

[Hedayet]

FIxed now?