-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Switch from sales tracked to payouts limit #2485
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git βοΈ
|
WalkthroughThis update replaces all references to "sales" usage and limits with "payouts" usage and limits throughout the application. Database schemas, API handlers, constants, UI components, and capability checks are updated to reflect this semantic shift from tracking sales revenue to tracking partner payouts. Related fee rates and feature descriptions are also revised. Additionally, some UI and API data mappings are refactored, and payout usage validation is introduced before confirming payouts. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant UI
participant API
participant DB
User->>UI: Views plan usage or settings
UI->>API: Requests workspace data
API->>DB: Query workspace (now with payoutsLimit)
DB-->>API: Return workspace data (with payoutsLimit)
API-->>UI: Return workspace data
UI->>User: Displays payouts usage and limits
sequenceDiagram
participant Stripe
participant WebhookHandler
participant DB
Stripe->>WebhookHandler: Checkout/session/subscription event
WebhookHandler->>DB: Update workspace (set payoutsLimit)
DB-->>WebhookHandler: Confirmation
WebhookHandler-->>Stripe: 200 OK
sequenceDiagram
participant User
participant API
participant DB
User->>API: Confirm payout request
API->>DB: Check if payoutsUsage < payoutsLimit
alt Payouts limit exceeded
API-->>User: Throw error "Payouts limit exceeded"
else
API->>DB: Proceed with payout and increment payoutsUsage
API-->>User: Confirm payout success
end
Poem
π Recent review detailsConfiguration used: CodeRabbit UI π Files selected for processing (3)
β Files skipped from review due to trivial changes (1)
π§ Files skipped from review as they are similar to previous changes (2)
β° Context from checks skipped due to timeout of 90000ms (1)
β¨ Finishing Touches
πͺ§ TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
π Outside diff range comments (1)
apps/web/ui/layout/sidebar/usage.tsx (1)
199-209: π οΈ Refactor suggestionRemove dead code related to sales formatting.
The
UsageRowcomponent still contains formatting logic specifically for "Sales" labels (currency formatting and "$" prefix), but no sales usage row is actually rendered. This creates dead code that should be cleaned up.Remove the sales-specific formatting logic:
<NumberFlow - value={label === "Sales" ? usage / 100 : usage} + value={usage} format={ - label === "Sales" - ? { - style: "currency", - currency: "USD", - maximumFractionDigits: 0, - } - : undefined + undefined } />{" "} of{" "} <motion.span className={cn( "relative transition-colors duration-150", showNextPlan && nextPlanLimit ? "text-neutral-400" : "text-neutral-600", )} > - {label === "Sales" ? "$" : ""} - {formatNumber(label === "Sales" ? limit / 100 : limit)} + {formatNumber(limit)} {/* ... rest of the JSX */} </motion.span>And also in the next plan display:
<motion.span className="ml-1 whitespace-nowrap text-xs font-medium text-blue-600"> - {label === "Sales" ? "$" : ""} - {formatNumber( - label === "Sales" ? nextPlanLimit / 100 : nextPlanLimit, - )} + {formatNumber(nextPlanLimit)} </motion.span>Also applies to: 219-221, 247-251
π§Ή Nitpick comments (1)
apps/web/ui/layout/sidebar/usage.tsx (1)
33-33: Consider removing unusedpayoutsLimit.The
payoutsLimitis destructured from the workspace but never used in this component. If it's not needed for the current usage display, consider removing it to keep the code clean.
π Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
π Files selected for processing (15)
apps/web/app/(ee)/api/stripe/webhook/checkout-session-completed.ts(1 hunks)apps/web/app/(ee)/api/stripe/webhook/customer-subscription-deleted.ts(1 hunks)apps/web/app/(ee)/api/stripe/webhook/customer-subscription-updated.ts(1 hunks)apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/billing/plan-usage.tsx(3 hunks)apps/web/lib/partners/constants.ts(1 hunks)apps/web/lib/plan-capabilities.ts(1 hunks)apps/web/lib/zod/schemas/workspaces.ts(1 hunks)apps/web/scripts/update-payouts-limits.ts(1 hunks)apps/web/tests/utils/schema.ts(1 hunks)apps/web/ui/layout/sidebar/app-sidebar-nav.tsx(1 hunks)apps/web/ui/layout/sidebar/conversions/conversions-onboarding.tsx(3 hunks)apps/web/ui/layout/sidebar/usage.tsx(3 hunks)packages/prisma/schema/workspace.prisma(1 hunks)packages/utils/src/constants/plan-compare.tsx(3 hunks)packages/utils/src/constants/pricing.tsx(5 hunks)
π§° Additional context used
𧬠Code Graph Analysis (2)
apps/web/app/(ee)/api/stripe/webhook/customer-subscription-deleted.ts (1)
packages/utils/src/constants/pricing.tsx (1)
FREE_PLAN(335-335)
apps/web/ui/layout/sidebar/conversions/conversions-onboarding.tsx (1)
apps/web/lib/plan-capabilities.ts (1)
getPlanCapabilities(4-14)
β° Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build
π Additional comments (17)
apps/web/ui/layout/sidebar/app-sidebar-nav.tsx (1)
195-195: LGTM! Good cleanup of unused parameter.The removal of the
sessionparameter from theuserSettingsfunction is a good improvement. The parameter was not being used within the function implementation, and this change brings consistency with the other navigation area functions (defaultandworkspaceSettings) which also don't require session data in their signatures. The session data remains available where actually needed through theuseSession()hook and is properly passed to theSidebarNavcomponent.apps/web/lib/partners/constants.ts (1)
7-8: LGTM: Fee reduction for business plan implemented correctly.The payout fee reduction for the business plan (ACH: 7% β 5%, card: 10% β 8%) is implemented correctly and aligns with the broader migration to payouts-based tracking.
apps/web/scripts/update-payouts-limits.ts (1)
5-12: Verify the significant limit reduction for business plan.The script correctly updates all business plan projects to have a
payoutsLimitof $25,000. However, according to the AI summary, the previoussalesLimitwas $50,000. Please confirm this 50% reduction is intentional and aligns with business requirements.apps/web/app/(ee)/api/stripe/webhook/customer-subscription-deleted.ts (1)
90-90:Details
β Verification successful
Verify FREE_PLAN.limits.payouts property exists.
The change correctly updates the subscription deletion logic to use
payoutsLimitinstead ofsalesLimit. However, please verify thatFREE_PLAN.limits.payoutsis properly defined to ensure the non-null assertion is safe.
π Script executed:
#!/bin/bash # Description: Verify FREE_PLAN has payouts property defined # Expected: Find FREE_PLAN definition with limits.payouts property # Search for FREE_PLAN definition and limits structure rg -A 10 -B 2 "FREE_PLAN.*=.*PLANS" packages/utils/src/constants/pricing.tsx # Search for payouts property in plan limits rg -A 5 -B 5 "payouts.*:" packages/utils/src/constants/pricing.tsxLength of output: 1593
FREE_PLAN.limits.payouts confirmed β non-null assertion safe
Verified that
FREE_PLAN.limits.payoutsis defined inpackages/utils/src/constants/pricing.tsx(value0for the Free plan), so usingFREE_PLAN.limits.payouts!is safe. Approving the change.apps/web/app/(ee)/api/stripe/webhook/checkout-session-completed.ts (1)
65-65: LGTM! Correct migration from sales to payouts tracking.The field replacement from
salesLimittopayoutsLimitis consistent with the broader refactor to switch from tracking sales to tracking partner payouts.apps/web/lib/plan-capabilities.ts (1)
12-12: Good addition of capability-based feature flag.The
canTrackConversionscapability provides a cleaner way to determine feature availability based on plan type rather than sales usage limits, which aligns well with the migration to payouts tracking.apps/web/app/(ee)/api/stripe/webhook/customer-subscription-updated.ts (1)
76-76: Consistent migration pattern across webhook handlers.The replacement of
salesLimitwithpayoutsLimitmaintains consistency with the other Stripe webhook handlers and correctly implements the schema migration.packages/utils/src/constants/pricing.tsx (1)
23-23: Systematic migration from sales to payouts limits looks correct.The replacement of
saleswithpayoutsacross all plan definitions is consistent and maintains the same limit values. The monetary values appear to be properly represented in cents.Also applies to: 57-57, 144-144, 242-242, 323-323
apps/web/tests/utils/schema.ts (1)
84-84: LGTM! Test schema correctly updated for payouts refactoring.The test schema correctly reflects the change from
salesUsageandsalesLimittopayoutsLimit, maintaining consistency with the workspace schema updates.apps/web/lib/zod/schemas/workspaces.ts (1)
51-55: LGTM! Proper schema validation for payouts limit.The schema correctly defines
payoutsLimitwith appropriate Zod validation and clear documentation specifying the field tracks partner payouts in cents. The type and validation are appropriate for monetary amounts.apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/billing/plan-usage.tsx (2)
45-45: LGTM! Correctly updated destructuring for payouts limit.The workspace destructuring correctly includes
payoutsLimitto support the new payouts tracking functionality.
119-127: LGTM! Dependencies correctly updated.The
useMemodependencies are properly updated to includepayoutsLimitinstead of the previous sales fields, ensuring the component re-renders when payouts data changes.packages/utils/src/constants/plan-compare.tsx (3)
229-238: LGTM! New automated payouts feature properly added.The new "Automated global payouts" feature is correctly configured with appropriate plan availability (business, advanced, enterprise) and proper documentation link.
246-260: LGTM! Consistent terminology update to partner payouts.The feature text is correctly updated from "tracked sales" to "partner payouts" with proper limit reference change from
plan.limits.salestoplan.limits.payouts. The messaging for plans without payouts is also consistently updated.
268-286: LGTM! Payout fee rates updated correctly.The payout fee structure is properly updated with business plan reduced from 7% to 5%, and consistent messaging for plans without payouts. The fee structure aligns with the new payouts-focused model.
apps/web/ui/layout/sidebar/conversions/conversions-onboarding.tsx (1)
3-3: Excellent architectural improvement using capability-based logic.The migration from checking specific
salesUsageandsalesLimitvalues to using thecanTrackConversionscapability flag fromgetPlanCapabilitiesis a much cleaner approach. This centralizes the business logic for determining feature availability and makes the code more maintainable.Also applies to: 18-22, 39-39
apps/web/ui/layout/sidebar/usage.tsx (1)
6-6: LGTM on the migration from sales to payouts tracking.The removal of sales-related imports, destructuring, and dependency updates are consistent with the PR objective.
Also applies to: 33-33, 70-70
apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/billing/plan-usage.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
π Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
π Files selected for processing (5)
apps/web/app/(ee)/admin.dub.co/(dashboard)/components/user-info.tsx(3 hunks)apps/web/app/(ee)/api/admin/impersonate/route.ts(2 hunks)apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/billing/plan-usage.tsx(4 hunks)apps/web/scripts/update-payouts-limits.ts(1 hunks)packages/utils/src/constants/pricing.tsx(7 hunks)
π§ Files skipped from review as they are similar to previous changes (2)
- apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/billing/plan-usage.tsx
- packages/utils/src/constants/pricing.tsx
π§° Additional context used
πͺ Biome (1.9.4)
apps/web/app/(ee)/admin.dub.co/(dashboard)/components/user-info.tsx
[error] 64-64: Missing key property for this element in iterable.
The order of the items may change, and having a key can help React identify which item was moved.
Check the React documentation.
(lint/correctness/useJsxKeyInIterable)
π Additional comments (5)
apps/web/app/(ee)/api/admin/impersonate/route.ts (2)
35-36: LGTM! Clean field mapping update.The change from
salesUsage/foldersUsagetousage/linksUsagealigns well with the broader refactor to remove sales tracking.
55-58: Good backward compatibility preservation.The mapping preserves the original totals under
totalClicks/totalLinkswhile providing current usage underclicks/links. This maintains API compatibility during the transition.apps/web/app/(ee)/admin.dub.co/(dashboard)/components/user-info.tsx (3)
3-3: LGTM! Appropriate import changes.Removing
currencyFormatterand addingnFormatteraligns with removing sales currency formatting and standardizing on numeric formatting.
15-16: Good addition of total metrics.Adding
totalClicksandtotalLinksprovides comprehensive usage visibility in the admin interface.
24-29: Excellent refactoring to eliminate code duplication.The
itemsarray approach cleanly replaces repetitive hardcoded stat blocks and makes the component more maintainable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
π Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
π Files selected for processing (5)
apps/web/app/(ee)/api/cron/payouts/confirm/confirm-payouts.ts(1 hunks)apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/billing/plan-usage.tsx(4 hunks)apps/web/lib/actions/partners/confirm-payouts.ts(1 hunks)apps/web/lib/zod/schemas/workspaces.ts(1 hunks)packages/prisma/schema/workspace.prisma(1 hunks)
π§ Files skipped from review as they are similar to previous changes (4)
- apps/web/lib/actions/partners/confirm-payouts.ts
- packages/prisma/schema/workspace.prisma
- apps/web/lib/zod/schemas/workspaces.ts
- apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/billing/plan-usage.tsx
π§° Additional context used
𧬠Code Graph Analysis (1)
apps/web/app/(ee)/api/cron/payouts/confirm/confirm-payouts.ts (2)
packages/email/src/index.ts (1)
sendEmail(6-29)packages/email/src/templates/partner-payout-confirmed.tsx (1)
PartnerPayoutConfirmed(18-122)
β° Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build
π Additional comments (1)
apps/web/app/(ee)/api/cron/payouts/confirm/confirm-payouts.ts (1)
141-150: LGTM: Correct implementation of payouts usage tracking.The database update correctly increments
payoutsUsageby the total payout amount within the transaction, ensuring consistency with the broader migration from sales to payouts tracking.
|
@CodeRabbit final review |
|
Tip For best results, initiate chat on the files or code changes. π§© Analysis chain@steven-tey I'll conduct a comprehensive final review of this major refactoring. Let me search for any potential issues or missed references. π Script executed: Length of output: 2105 π Script executed: Length of output: 80540 π Script executed: Length of output: 2016 π Script executed: Length of output: 1518 @steven-tey Excellent work! π This is a comprehensive and well-executed refactoring. I've conducted a thorough analysis and found the migration from sales tracking to payouts limits to be complete and consistent across all layers. β What's Working PerfectlyComplete Migration:
Robust Implementation:
Business Logic Updates:
Test Coverage:
π― Architecture AssessmentThe refactoring demonstrates excellent architectural thinking: graph TB
A[Database Schema] --> B[API Layer]
B --> C[Business Logic]
C --> D[UI Components]
D --> E[User Experience]
A1[payoutsUsage/payoutsLimit] --> B1[Stripe Webhooks]
B1 --> C1[Validation Logic]
C1 --> D1[Usage Display]
D1 --> E1[Partner Dashboard]
The change correctly shifts focus from revenue tracking to partner payout management, which aligns perfectly with a partner program's core functionality. π Ready for ProductionThis PR represents a textbook example of a large-scale refactoring done right:
The implementation is production-ready! |
Summary by CodeRabbit
New Features
Enhancements
Improvements
Bug Fixes
Chores