Subscriptions: use djstripe for products/features #10238
Conversation
stsewd
requested review from
ericholscher and
humitos
and removed request for
a team and
agjohnson
|
Don't think this needs a review from the frontend team, but I did a small change in two templates. |
| id__in=stripe_products_id, | ||
| prices__subscription_items__subscription__rtd_organization=organization, | ||
| ).values_list("id", flat=True) | ||
| # TODO: maybe we should merge features from multiple products? |
There was a problem hiding this comment.
Can you expand a little more on this? I'm not sure to understand this question.
There was a problem hiding this comment.
A subscription can have multiple products, (like the normal basic plan + an extra builder). Right now we are just selecting one product, instead of doing that we could:
- Select the first feature found from iterating over all products (or select the one with the larger value)
- Merge the features from all products (basic plan has 2 builders, and the extra builder plan has 1, so we merge the values of all of them, returning a feature with the number
3) - Alternative we can just create a custom product that includes all things from the basic plan + the extra builder.
Since we already have this case in one of our subscriptions, we should make a decision how we want to handle this, cc @ericholscher
There was a problem hiding this comment.
Hrm, good point. I'd like to make it easy to inclucde "addons" to an existing plan, if at all possible. This gives us a bit more flexibility in how we're defining products (eg. the extra builder).
I don't have a strong preference for how it's actually implemented. I think selecting the largest is probably the most obvious, and we'd just need to update the +1 builder to be 3 total builders basically? But I'm not 100% sure.
|
Okay, added support for "extra products". They are now listed in the subscription detail view, and the
|
docs/dev/subscriptions.rst
Outdated
| and can have multiple prices of products attached to it. | ||
| A product can have multiple prices, usually monthly and yearly. |
There was a problem hiding this comment.
So there's multiple prices of products, and also products can have multiple prices? I don't quite understand why we would have 2 different prices for the same product on a subscription?
There was a problem hiding this comment.
| and can have multiple prices of products attached to it. | |
| A product can have multiple prices, usually monthly and yearly. | |
| and can have multiple products attached to it. | |
| A product can have multiple prices, usually monthly and yearly. |
I think this is clearer?
There was a problem hiding this comment.
A subscription is attached to a price, not a product, but don't think you can have a subscription attached to several prices of the same product, yeah.
|
|
||
| To subscribe an organization to an extra product, | ||
| you just need to add the product to its subscription with the desired quantity, | ||
| our appliction will automatically relate this new product to the organization. |
|
Anything else needed to merge this PR? The only answer missing is in #10238 (comment), I can apply that change if needed. |
|
I think we're good to ship this on my side. Merging that comment update is probably useful to clarify things 👍 |
Instead of relying on our subscription models, we are now relying on the djstripe models, but the features of each subscription are still attached to our subscription models. In the new modeling, we have features attached to stripe products.
I'm using some data classes to make the representation instead of using plain dictionaries, they are more verbose than a plain dictionary, but are easier to manipulate in the code.
After this change has been deployed, we won't be needing our subscription models anymore. The available products are defined in .com, since in .org we don't have subscriptions. If we feel like we can have this in the DB, we can also switch the data classes to be Django models.
Closes #9313