feat: first PR for Usage dashboard #26807
Conversation
patricio-posthog
requested review from
zlwaterfield,
raquelmsmith and
surbhi-posthog
|
Size Change: +145 B (+0.01%) Total Size: 1.11 MB ℹ️ View Unchanged
|
There was a problem hiding this comment.
I love the speed here but I think we should think this through just a little more. I am thinking more of a structure like the current settings page where we do /[...path to settings]/billing and /[...path to settings]/usage as two different URLs so we can control access to the pages and support more pages of that structure in the future.
I agree 100%. My idea was to have a root path and then two internal sections, as you said, with But in the future it would be And thanks for the quick review! |
|
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the |
|
This PR was closed due to lack of activity. Feel free to reopen if it's still relevant. |
|
@zlwaterfield as discussed the other day, fort he initial PR for the new billing & usage dashboards, the URLs will be |
frontend/src/scenes/urls.ts
Outdated
| @@ -209,6 +209,8 @@ export const urls = { | |||
| // Cloud only | |||
| organizationBilling: (products?: ProductKey[]): string => | |||
| `/organization/billing${products && products.length ? `?products=${products.join(',')}` : ''}`, | |||
| organizationBillingOverview: (): string => `/organization/billing/overview`, | |||
There was a problem hiding this comment.
This pattern is good for now but we may want to move to how settings is done (look above in file) where it's a function that passes in the section id for the page.
There was a problem hiding this comment.
Moved into a function that receives a BillingSectionId
| @@ -0,0 +1,31 @@ | |||
| .BillingSection { | |||
There was a problem hiding this comment.
We're trying to move away from scss so it's best to use inline tailwind styling now. LLMs are good at converting this if you need help.
There was a problem hiding this comment.
Removed, thanks!
| to={ | ||
| featureFlags[FEATURE_FLAGS.BILLING_USAGE_DASHBOARD] | ||
| ? urls.organizationBillingOverview() | ||
| : urls.organizationBilling() |
There was a problem hiding this comment.
There are quite a few instances of this call so I think it might be better to change in the function
E.g.
organizationBilling: (products?: ProductKey[]): string =>
featureFlags[FEATURE_FLAGS.BILLING_USAGE_DASHBOARD]
? `/organization/billing/overview${products && products.length ? `?products=${products.join(',')}` : ''}`,
: `/organization/billing${products && products.length ? `?products=${products.join(',')}` : ''}`,
There was a problem hiding this comment.
I only found one instance of this, so I don't know if it's a good idea to create a function for this now. Maybe in the future?
There was a problem hiding this comment.
I see 12 instances and it will also make it so if anyone adds another this this doesn't get missed. Change one place instead of 12.
There was a problem hiding this comment.
Ahhhh I haven't thought in change those yet. I was looking for instances where the if feature flag was already implemented. Ok, going to do this.
Problem
We are planning to add an Usage dashboard, where organizations will be able to see some information about their events consumptions and general usage in the current period. It will be part of Billing.
This first PR introduces the feature flag that will be used in this project (
billing-usage-dashboard) and minor cosmetics changes, so we can get ahead on this.Changes
billing-usage-dashboardBillingtoBiling & UsageorganizationBillingUsagescene that has two links in the left navigation, and will link to each section (similar toSettings)👉 Stay up-to-date with PostHog coding conventions for a smoother review.
Does this work well for both Cloud and self-hosted?
It doens't have an impact.
How did you test this code?
Test it locally, checking that the changes do not affect anything if the feature flag is not present.