The latest updates on your projects. Learn more about Vercel for Git ↗︎

@CodeRabbit final review pls

Walkthrough

The changes add support for editing a partner's email address in the profile form, with conditional disabling and tooltips if payouts have been completed. The backend schema and update logic are updated to require and validate the email field, and to restrict email changes if payouts exist, aligning with existing restrictions on other sensitive fields.

Changes

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant ProfileForm
    participant ConfirmationDialog
    participant BackendAction

    User->>ProfileForm: Edit email/country/profile type
    ProfileForm->>User: Disable fields or show tooltip if payouts exist
    User->>ProfileForm: Click "Save changes"
    alt Stripe Connect ID present
        ProfileForm->>ConfirmationDialog: Show warning about resetting Stripe
        ConfirmationDialog->>User: Prompt for confirmation
        User->>ConfirmationDialog: Confirm/Cancel
        alt User cancels
            ConfirmationDialog->>ProfileForm: Abort submission
        else User confirms
            ProfileForm->>BackendAction: Submit updated profile data
        end
    else
        ProfileForm->>BackendAction: Submit updated profile data
    end
    BackendAction->>ProfileForm: Success/Error response

Poem

A bunny with code on its mind,
Hopped in and made email refined.
With tooltips and checks for payouts past,
Now changes to profiles are safe and steadfast.
Stripe and forms in harmony dwell—
The dashboard’s improved, and all is well!
🐇✨

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

#!/bin/bash
# Read the partner profile page client component
cat "apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/page-client.tsx"

#!/bin/bash
# Read the update partner profile action
cat "apps/web/lib/actions/partners/update-partner-profile.ts"

#!/bin/bash
# Check git diff to see what specific changes were made
git diff HEAD~1 HEAD -- "apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/page-client.tsx" "apps/web/lib/actions/partners/update-partner-profile.ts"

#!/bin/bash
# Look for any related types or interfaces that might be relevant
fd -e ts -e tsx -x grep -l "PartnerProfile\|updatePartnerProfile" {} \;

#!/bin/bash
# Check for any validation schemas or types related to partner profile
rg "PartnerProfile" -A 5 -B 5 --type ts --type tsx

#!/bin/bash
# Check for PartnerProfile types and schemas with correct file extensions
rg "PartnerProfile" -A 5 -B 5 --type ts

#!/bin/bash
# Look at the partner profile schema
cat "apps/web/lib/zod/schemas/partner-profile.ts"

#!/bin/bash
# Check the types file for PartnerProps definition
cat "apps/web/lib/types.ts" | grep -A 20 -B 5 "PartnerProps"

#!/bin/bash
# Check for any recent commits on these files to understand the changes
git log --oneline -10 -- "apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/page-client.tsx" "apps/web/lib/actions/partners/update-partner-profile.ts"

#!/bin/bash
# Check for any validation or error handling patterns
rg "completedPayoutsCount" -A 3 -B 3 --type ts

@steven-tey Looking at your partner profile update implementation, this is a well-structured feature with solid business logic and security considerations. Here's my final review:

✅ Strengths

Security & Validation:

• Proper server-side validation matching client-side restrictions
• Authentication with authPartnerActionClient
• Input sanitization and file upload restrictions (2MB limit)
• Protection against unauthorized profile changes

Business Logic:

• Excellent handling of payout restrictions - partners with completed payouts can't change critical fields
• Smart Stripe account cleanup when restricted fields are modified
• Proper error messages explaining restrictions to users

User Experience:

• Great accessibility with tooltips explaining disabled fields
• Responsive form with proper loading states
• Clear visual feedback for restricted actions
• Smooth animations for conditional company name field

Code Quality:

• Good TypeScript usage with proper type definitions
• Effective use of React Hook Form for form management
• Proper separation of concerns between client and server code
• Clean error handling with user-friendly messages

🔧 Minor Suggestions

Component Organization:
The ProfileForm component is quite large (~200 lines). Consider extracting smaller components:

// Extract field components
<EmailField completedPayoutsCount={completedPayoutsCount} />
<CountryField completedPayoutsCount={completedPayoutsCount} />
<ProfileTypeField completedPayoutsCount={completedPayoutsCount} />

Code Duplication:
The completedPayoutsCount > 0 checks could be extracted to a custom hook:

const useFieldRestrictions = (completedPayoutsCount: number) => ({
  isRestricted: completedPayoutsCount > 0,
  getTooltip: (fieldName: string) => `Since you've already received payouts...`,
  getFieldProps: (fieldName: string) => ({ disabled: completedPayoutsCount > 0 })
});

📋 Technical Notes

Image Handling: The conditional image upload logic is clean:

image: imageChanged ? data.image : null

Form Validation: The Zod schema properly handles the company name requirement:

.refine((data) => data.profileType === "company" ? !!data.companyName : true)

Cache Invalidation: Good use of qstash for invalidating partner caches when image/name changes.

🎯 Overall Assessment

This is production-ready code that demonstrates solid understanding of:

• Complex form handling with business rules
• Security best practices
• User experience considerations
• Integration with external services (Stripe)

The implementation properly balances user flexibility with business requirements around payout restrictions. The code is maintainable and follows React/Next.js best practices.

Approved ✅ - This feature is ready for deployment with excellent attention to security, UX, and business logic requirements.

@CodeRabbit final review

#!/bin/bash
# Read the main files involved in this PR to understand the implementation
echo "=== Frontend Profile Form Component ==="
cat "apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/page-client.tsx"

echo -e "\n=== Backend Update Action ==="
cat "apps/web/lib/actions/partners/update-partner-profile.ts"

echo -e "\n=== Check for any validation schemas ==="
find apps/web/lib -name "*.ts" -exec grep -l "updatePartnerProfile\|PartnerProfile" {} \; | head -5

@steven-tey Looking at your partner profile update implementation, this is a well-structured feature with solid business logic and security considerations. Here's my final review:

✅ Strengths

Security & Validation:

• Proper server-side validation matching client-side restrictions
• Authentication with authPartnerActionClient
• Input sanitization and file upload restrictions (2MB limit)
• Protection against unauthorized profile changes

Business Logic:

• Excellent handling of payout restrictions - partners with completed payouts can't change critical fields
• Smart Stripe account cleanup when restricted fields are modified
• Proper error messages explaining restrictions to users

User Experience:

• Great accessibility with tooltips explaining disabled fields
• Responsive form with proper loading states
• Clear visual feedback for restricted actions
• Smooth animations for conditional company name field

Code Quality:

• Good TypeScript usage with proper type definitions
• Effective use of React Hook Form for form management
• Proper separation of concerns between client and server code
• Clean error handling with user-friendly messages

🔧 Minor Suggestions

Component Organization:
The ProfileForm component is quite large (~200 lines). Consider extracting smaller components:

// Extract field components
<EmailField completedPayoutsCount={completedPayoutsCount} />
<CountryField completedPayoutsCount={completedPayoutsCount} />
<ProfileTypeField completedPayoutsCount={completedPayoutsCount} />

Code Duplication:
The completedPayoutsCount > 0 checks could be extracted to a custom hook:

const useFieldRestrictions = (completedPayoutsCount: number) => ({
  isRestricted: completedPayoutsCount > 0,
  getTooltip: (fieldName: string) => `Since you've already received payouts...`,
  getFieldProps: (fieldName: string) => ({ disabled: completedPayoutsCount > 0 })
});

📋 Technical Notes

Image Handling: The conditional image upload logic is clean:

image: imageChanged ? data.image : null

Form Validation: The Zod schema properly handles the company name requirement:

.refine((data) => data.profileType === "company" ? !!data.companyName : true)

Cache Invalidation: Good use of qstash for invalidating partner caches when image/name changes.

🎯 Overall Assessment

This is production-ready code that demonstrates solid understanding of:

• Complex form handling with business rules
• Security best practices
• User experience considerations
• Integration with external services (Stripe)

The implementation properly balances user flexibility with business requirements around payout restrictions. The code is maintainable and follows React/Next.js best practices.

Approved ✅ - This feature is ready for deployment with excellent attention to security, UX, and business logic requirements.