Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for a free plan #24

Closed
dulacp opened this issue Nov 7, 2013 · 9 comments · Fixed by searchstax/django-plans#1
Closed

Support for a free plan #24

dulacp opened this issue Nov 7, 2013 · 9 comments · Fixed by searchstax/django-plans#1

Comments

@dulacp
Copy link
Contributor

dulacp commented Nov 7, 2013

It appears that there is not a real support for a free plan.
The spec is something like this for me


Spec

  • there can only be one free plan (mutiple free plans it doesn't make sense)
  • a free plan doesn't have an expiration date
  • when the new user grace period ended it falls back to a free default plan if one exists and if quota validations passed

I'm willing to contribute to this one, just want to discuss the specificities with you a little bit, because I'm sure you've already thought about it.

@cypreess
Copy link
Collaborator

cypreess commented Nov 8, 2013

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
Copy link
Contributor Author

dulacp commented Nov 8, 2013

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
Copy link
Contributor

brentc commented Feb 27, 2014

Did anything come of this?

@andr0s
Copy link

andr0s commented Mar 19, 2014

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

@brentc
Copy link
Contributor

brentc commented Mar 29, 2014

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
Copy link
Contributor

brentc commented Mar 29, 2014

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
Copy link
Collaborator

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
Copy link
Contributor

brentc commented Mar 30, 2014

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

brentc added a commit to kira/django-plans that referenced this issue Mar 30, 2014
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
shahdewang pushed a commit to searchstax/django-plans that referenced this issue Nov 6, 2014
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.

Signed-off-by: Devang Shah <shahd@vmware.com>
marcinmazurek pushed a commit to marcinmazurek/django-plans that referenced this issue Dec 5, 2014
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
@Hedayet
Copy link

Hedayet commented Feb 13, 2018

FIxed now?

PetrDlouhy pushed a commit to PetrDlouhy/django-plans that referenced this issue Oct 20, 2018
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
PetrDlouhy pushed a commit to PetrDlouhy/django-plans that referenced this issue Oct 20, 2018
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
PetrDlouhy pushed a commit to PetrDlouhy/django-plans that referenced this issue Oct 20, 2018
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
PetrDlouhy pushed a commit to PetrDlouhy/django-plans that referenced this issue Oct 20, 2018
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
PetrDlouhy pushed a commit to PetrDlouhy/django-plans that referenced this issue Nov 21, 2018
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
PetrDlouhy pushed a commit to PetrDlouhy/django-plans that referenced this issue Nov 21, 2018
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
PetrDlouhy pushed a commit to PetrDlouhy/django-plans that referenced this issue Nov 24, 2018
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
PetrDlouhy pushed a commit to PetrDlouhy/django-plans that referenced this issue Nov 24, 2018
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
PetrDlouhy pushed a commit to PetrDlouhy/django-plans that referenced this issue Feb 1, 2019
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
PetrDlouhy pushed a commit to PetrDlouhy/django-plans that referenced this issue Feb 2, 2019
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
PetrDlouhy pushed a commit to PetrDlouhy/django-plans that referenced this issue Feb 2, 2019
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
PetrDlouhy pushed a commit to PetrDlouhy/django-plans that referenced this issue Feb 2, 2019
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
PetrDlouhy pushed a commit to PetrDlouhy/django-plans that referenced this issue Dec 19, 2019
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
PetrDlouhy pushed a commit to PetrDlouhy/django-plans that referenced this issue Dec 19, 2019
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
PetrDlouhy pushed a commit to PetrDlouhy/django-plans that referenced this issue Dec 19, 2019
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
PetrDlouhy pushed a commit to PetrDlouhy/django-plans that referenced this issue Dec 19, 2019
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
PetrDlouhy pushed a commit to PetrDlouhy/django-plans that referenced this issue Jan 4, 2020
Fixes django-getpaid#24

Plans without pricings will be `plan.is_free: true`. Switching to these
plans causes the userplan have it's expiry cleared.

Since there's no expiry set, the standard plan change process doesn't
make sense, so the plan table is adjusted to present the standard plan
order links rather than plan change links.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants