Plans: settings.py vs. models.py about dj-stripe

[briandant]

@pydanny: I've create a Plan model in my fork of this project, and I'd like to submit it back, if you're interested. If you think I'm on the right path, I'd be happy to make this work with the current pattern (Plans in settings.py), or work to deprecate that feature, as mentioned in the docs.

I'm not using the views or templates in this project, so haven't thought about where to start working the plan model in; would love to hear your thoughts on how that should work. Would you rather I just took a stab at implementing Plans in the views and templates, or do you have opinions about what you want that to look like?

Here's what my models.py and admin.py look like now:
https://github.com/briandant/dj-stripe/blob/feature/plans-as-models/djstripe/models.py#L882
https://github.com/briandant/dj-stripe/blob/feature/plans-as-models/djstripe/admin.py#L296

[pydanny]

Hey - I'm not currently working on a project that needs this so it's hard for me to make time to look at your code properly. However @dollydagr is working on something and has full commit rights on the project. I hope she can make time to review this!

As for the global idea of moving plans out of settings, I started to do that a while ago. I backed off because I wanted to make it impossible for untechnical users to be able to switch things back and forth willy-nilly. So if this gets implemented, there should be a developer-level settings toggle for having plans to be managed either via settings.py or the Plan model. Does that make sense?

[briandant]

Yep, that makes sense. I'll look for a note from @dollydagr. Thx!

[dollydagr]

@briandant, thanks for the feature!

I have some questions:

• The plans' creation is enabled (for the developer) in the admin page, correct?
• Are you thinking of adding a creation interface in the templates/views for the end user (customer)?
• Would this feature allow having multiple subscriptions per customer?

I just wanted to test my understanding before I review your code.
Will try to do this in the next days.

[briandant]

Hey @dollydagr! Thanks for the quick response.

Your questions

• The plans' creation is enabled (for the developer) in the admin page, correct?

Yes.

• Are you thinking of adding a creation interface in the templates/views for the end user (customer)?

I could. However, I wouldn't need that feature for my current project, so it wouldn't happen right away.

• Would this feature allow having multiple subscriptions per customer?

I haven't thought about that yet. Oh, look! As of last month, Stripe now supports multiple subscriptions, which resolves @dmpayton's original issue. 😄 I'd be happy to talk about what that implementation looks like, and help with it as time allows.

Next steps

Given how I'm using this package, and the timelines for that project, my next priority won't be to implement the multi-subscription or the customer plan-creation feature. However, I'm getting a ton of benefit from this package, so I really want to help.

So ... if you want to review now, I'll commit to the work for fully supporting Plans as models or settings.py (and presenting those options to the user). Or, we could wait until I have more time and implement all three features together (next month?). Do you have a preference?

[pydanny]

I prefer incremental changes over broad sweeping changes. Makes migrations much easier for existing projects and the code tends to be more stable.

As the code progresses

[pydanny]

... we'll cut releases as needed.

[lgunsch]

I have had some time recently to start working on finishing up this feature. I have a rough-draft start here: https://github.com/lgunsch/dj-stripe/commit/b6744250ad0c9054aca46d688112fec386d77ee0. My goal was to migrate plan_from_stripe_id into the Plan model where the logic to select between settings plans and model plans could be contained, rather then sprinkling that logic all over the place. The same API can be used regardless of whether settings plans or model plans are being used.

[briandant]

Great to see that you got some time to make progress on this!

www.bdant.net || @briandant http://www.twitter.com/briandant || c:
919.421.4273 || skype: brian.dant

On Fri, Apr 25, 2014 at 12:19 PM, Lewis [email protected] wrote:

I have had some time recently to start working on finishing up this
feature. I have a rough-draft start here: lgunsch@b674425https://github.com/lgunsch/dj-stripe/commit/b6744250ad0c9054aca46d688112fec386d77ee0.
My goal was to migrate plan_from_stripe_id into the Plan model where the
logic to select between settings plans and model plans could be contained,
rather then sprinkling that logic all over the place. The same API can be
used regardless of whether settings plans or model plans are being used.

—
Reply to this email directly or view it on GitHubhttps://github.com/pydanny/dj-stripe/issues/22#issuecomment-41411243
.

[pydanny]

Note: I just explored how Stripe handles modifications of plans yesterday. Hence why this comment is so late to the party.

The Problem

The problem with Stripe plans as models is that except for the title and card description (what shows up on a statement) Stripe plans are immutable. Also, if you delete a plan then unless we add some code, the users who were under that original plan stay that way. They would have to be transferred. Therefore, modifying stripe plans involves more than what we assumed. On a model update it will require:

1. Creating a new plan
2. Moving (or not moving) all the customers on the old plan to the new plan via the stripe API.
3. Deleting the old plan (or not).
4. Keeping abstraction down so we have a maintainable, audit-able code base. We're dealing with money, so security is really important.

These add the following issues:

• In regards to No 2 above, moving all customers from one plan to another isn't something that should be done through the admin. Imagine if you have 5,000 or 100,000 users!
• Also for No 2, what if you want to grandfather in current users of a plan? Then we would need to have a flag that if a subscription is changed, whether or not users are transferred.
• In regards to No 3, the use case for No 2 means that we wouldn't want to delete plans all the time. Also, some people might want to retain plans inside of Stripe for security reasons.
• In regards to No 4, we'll have to do lots of heavy-duty logic around pre-saves, post-saves, and more. This makes the code harder to understand and debug.
• How does creating plan models help more with multiple customer subscriptions than a static system? Maybe database integrity?
• What edge cases are there that we haven't considered?

What should we do?

I've got two ideas:

Plan One:P Stick the current system

I can easily argue that we shouldn't create a Plan model. There would be way too much custom logic to support this, making me think that plan changes should be done by developer controls.

The downside is that making this work with multiple subscriptions in a Char field in the Customer model is going to be ugly.

Plan Two

All plans would be represented as a static Plan model. Once a Plan model is created, only the title, description, and active fields could be displayed. Migrating users from one plan to another would have to be done by custom script. We would overload the save(), pre_save(), and other methods to prevent abuse of this model.

This works great for database integrity.

References:

• https://stripe.com/docs/api#update_plan
• https://stripe.com/docs/api#delete_plan

[pydanny]

Oops, forgot a few things in regards to Plan 2:

1. Static Model Plans would be defined within settings. In fact, I don't want to provide an admin.py UI button for creating them.
2. Even with the addition of Static Model Plans, creating or modifying plans should be a developer activity, not something anyone with staff rights can do via the front end.

[lgunsch]

Either option looks fine to me. I can come up with arguments for both options.

What benefits is there to having plans as models? I suppose it would allow for dynamic creation of plans. For my particular use case, having support for multiple plan subscription gets rid of the need to dynamically create plans.

[pydanny]

Plans as models are there so we have elegant UI interactions, especially when we have multiple subscriptions per user (or company if we have flexible models for who is paying). The Plan models would not be editable once created, hence the term 'StaticModels'.

NOTE: Trying not to be a jerk here, but dynamic creation/modification/deletion of plans is not something I'm interested in adding to dj-stripe. That would involve too much custom logic with too many edge cases, and no developer or customer of it would be happy. While I can think of use cases for it (e.g. a project that allows people to set up their own subscription services), the amount of effort (testing, views, html, making setup easy, etc) goes what beyond what I've envisioned dj-stripe to do. I think it just involves too much custom logic.

What I'm working on now is an implementation of my idea of Static Plan Models. I should hopefully have it ready in 2-4 days for people to look at. ;-)

Consulting Note: Of course, if someone were to offer me (and @dollydagr if she is up to it) lots and lots of consulting money to work on dynamic plan models, I might change my mind. I would probably run that out of djstripe.contrib in order to isolate how that works.

[unformatt]

I'm confused where this ended up in the normal djstripe usage. From what I can tell, I still specify my plans in my settings and the Plan model is unused, with an empty table in my database.

[kavdev]

We haven't yet come to a decision on this. Most likely, you'll eventually add plans via the Plan model instead of in settings.py. Again, nothing's set in stone yet.

[kavdev]

Will be implemented for #307.

See also:
https://github.com/pydanny/dj-stripe/pull/174#issuecomment-120808144 and comments thereafter.