Subscriptions: use stripe price instead of relying on plan object

[stsewd]

• Have a setting with the stripe id of the price instead of the slug of the Plan object.
  We still need the plan object, but now this is separate from the djstripe subscription object.
• Separate the creation of our subscription object with the creation of a stripe subscription.
• Use the stripe customer object from the db instead of fetching it from stripe
  to decide if we should update the customer information
• Allow updating the metadata, this is in case the org changes its slug,
  we save the ID too, but is nice to have the slug updated too.

---

📚 Documentation previews 📚

• User's documentation (docs): https://docs--9640.org.readthedocs.build/en/9640/

• Developer's documentation (dev): https://dev--9640.org.readthedocs.build/en/9640/

[stsewd]

the stripe id was the same as the slug :D

[humitos]

yeah, this was done on purpose when we created these objects on Stripe

[stsewd]

our subscriptions should be correct now, we don't need to use this queryset anymore (excluding canceled subs), if the last subs was canceled we allow the user to buy a new one.

[stsewd]

we could still leave this warning (on subscriptions/utils.py where this code was moved), but I think it makes more sense to query all of our subs searching for cases like this and decide what to do if any.

[humitos]

I think I'm fine trusting that our data is consistent. However, if it's not, how we will detect this? This code at least gave us some hint were to look at when Stripe data was inconsistent.

We added it to detect these cases because we weren't sure which ones were those customers.

[stsewd]

We have 0 cases of more than one active subs

In [11]: from djstripe import models as djstripe
    ...: from django.db import models
    ...: 
    ...: subquery = models.Subquery(
    ...:     djstripe.Subscription.objects
    ...:     .filter(customer=models.OuterRef("id"), status="active")
    ...:     .annotate(count=models.Count("id"))
    ...:     .values("count")
    ...: )
    ...: 
    ...: q = djstripe.Customer.objects.annotate(active_subs_count=subquery).filter(active_subs_count__gt=1)

In [12]: q.count()
Out[12]: 0

Should we still have this warning?

[stsewd]

Same on .org

[stsewd]

I'm merging this, so I can create a new PR with some changes I have, with main as base instead of this branch as base. Let me know if you still think we should log this, I can just open a new PR for that.

[humitos]

yeah, this was done on purpose when we created these objects on Stripe

[humitos]

I think I'm fine trusting that our data is consistent. However, if it's not, how we will detect this? This code at least gave us some hint were to look at when Stripe data was inconsistent.

We added it to detect these cases because we weren't sure which ones were those customers.

[humitos]

I don't think the complexity of this for is required. We could just do:

current_metadata.update(org_metadata)
fields_to_update["metadata"] = current_metadata

which will add new fields and update only the fields that have changed.

[stsewd]

We will save one request in case the data hasn't changed, otherwise we will hit the stripe API every time the organization is updated.