fix(billing): return service/asset usage for current period TASK-1327 #5326
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…od, regardless of whether it is monthly or yearly and update tests accordingly
jamesrkiger
changed the title
Guitlle
approved these changes
Dec 12, 2024
…ASK-1328 (#5356) ### 📣 Summary Adjusts frontend types and handling of data service/asset usage data according to the changes in #5326. ### 📖 Description Previously, the ServiceUsageSerializer and AssetUsageSerializer returned usage information calculated according to a monthly billing cycle and a yearly billing cycle, regardless of what kind of billing cycle a user was actually subscribed to. So if a user was on a monthly plan, we made up a hypothetical yearly cycle and returned data for that in addition to the actual monthly cycle they are on. The frontend, in turn, selected the correct cycle information to display based on a separate request fetching the user’s subscription information. The hypothetical periods have been removed from the backend, which now returns only data for "current_period". This PR updates the frontend to handle this new data format. ### 👀 Preview steps 1. Create a new user on a Stripe-enabled instance 2. Navigate to usage page. Observe that user is on community plan with start date corresponding to account creation date. Displayed usage period should correspond to either first day of this month or last day of previous month (most likely the latter, though it currently depends on one’s timezone) and the last day of this month. 3. Purchase a monthly plan and sync djstripe Subscriptions, navigate to usage page. Observe that start date is still account creation date. Displayed usage period should now correspond to start date and one month after start date. 4. Cancel plan as the user, then cancel the plan via Stripe (or ask someone to do this), and sync subscriptions. Visit usage page and observe dates have not changed (because your community plan dates now correspond to date of cancellation and one month later). 5. Sign up for a yearly plan and sync subscriptions. Visit usage page and observe that start date remains the same, while displayed usage period ends a year from today.
jamesrkiger
deleted the
task-1327-return-only-relevant-cycle-for-service-usage
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
📣 Summary
Update asset and service usage code to return only a single set of data for the current billing cycle, regardless of whether that cycle is monthly or yearly and adjust frontend accordingly.
📖 Description
Currently, the
ServiceUsageSerializerandAssetUsageSerializerreturn usage information calculated according to a monthly billing cycle and a yearly billing cycle, regardless of what kind of billing cycle a user is actually subscribed to. So if a user is on a monthly plan, we make up a hypothetical yearly cycle and return data for that in addition to the actual monthly cycle they are on. The frontend, in turn, selects the correct cycle information to display based on a separate request fetching the user’s subscription information. The hypothetical cycle is never displayed and doesn’t seem to be used for anything at all.This PR merges the functionality of the
get_monthly_billing_dates()andget_yearly_billing_dates()utils into a single function that, once it determines which cycle an account is on, returns the relevantperiod_startandperiod_enddates.👀 Preview steps
For frontend preview:
Create a new user on a Stripe-enabled instance
Navigate to usage page. Observe that user is on community plan with start date corresponding to account creation date. Displayed usage period should correspond to either first day of this month or last day of previous month (most likely the latter, though it currently depends on one’s timezone) and the last day of this month.
Purchase a monthly plan and sync djstripe Subscriptions, navigate to usage page. Observe that start date is still account creation date. Displayed usage period should now correspond to start date and one month after start date.
Cancel plan as the user, then cancel the plan via Stripe (or ask someone to do this), and sync subscriptions. Visit
usage page and observe dates have not changed (because your community plan dates now correspond to date of cancellation and one month later).
Sign up for a yearly plan and sync subscriptions. Visit usage page and observe that start date remains the same, while displayed usage period ends a year from today.