When I cancel a subscription, Subscription.start is also updated to the date when the subscription was canceled. I haven't investigated deeper but this behaviour looks wrong. According to the code, Subscription.start is the "date the subscription started".
Here is the trace of the commands I ran
>>> su = Subscription.objects.last()
>>> su.cancel_at_period_end
False
>>> su.start
datetime.datetime(2019, 3, 6, 14, 47, 51, tzinfo=<UTC>)
>>> su.current_period_start
datetime.datetime(2019, 3, 6, 14, 47, 51, tzinfo=<UTC>)
>>> su.current_period_end
datetime.datetime(2019, 3, 31, 22, 0, tzinfo=<UTC>)
>>> su.cancel()
<Subscription: *****@*****.*** on **************>
>>> su = Subscription.objects.last()
>>> su.cancel_at_period_end
True
>>> su.start
datetime.datetime(2019, 3, 6, 15, 44, 29, tzinfo=<UTC>)
>>> su.current_period_start
datetime.datetime(2019, 3, 6, 14, 47, 51, tzinfo=<UTC>)
>>>
>>> su.current_period_end
datetime.datetime(2019, 3, 31, 22, 0, tzinfo=<UTC>)
>>> su.canceled_at
datetime.datetime(2019, 3, 6, 15, 44, 29, tzinfo=<UTC>)
I noticed the same thing, according to stripe's documentation for the subscription object, the start attribute is the date of the last substantial change to this subscription (the name is misleading). The method is_status_temporarily_current on the Subscription model will always return False because self.start will always equal self.cancelled_at.
Maybe something like this could work ?
def is_status_temporarily_current(self):
return (self.canceled_at and self.cancel_at_period_end and datetime.utcnow().replace(tzinfo=utc) < self.current_period_end)
Most helpful comment
I noticed the same thing, according to stripe's documentation for the subscription object, the
startattribute is thedate of the last substantial change to this subscription(the name is misleading). The methodis_status_temporarily_currenton theSubscriptionmodel will always returnFalsebecauseself.startwill always equalself.cancelled_at.Maybe something like this could work ?