fix: dataroom index

[mfts]

Summary by CodeRabbit

• Refactor
  • Updated access control logic to combine feature flag checks with existing plan-based permissions for dataroom indexing operations.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
papermark	Ready	Preview	Comment	Nov 17, 2025 9:46pm

[coderabbitai]

Walkthrough

Updates feature flag gating logic for dataroom index rebuild functionality across the UI component and API endpoint. Changes permission checks from plan-based-only to a combined condition using feature flags and plan presence, allowing both feature flag enabled users and datarooms-plus plan subscribers to proceed.

Changes

Cohort / File(s)	Summary
Dataroom Index Rebuild Feature Gating components/datarooms/actions/rebuild-index-button.tsx, pages/api/teams/[teamId]/datarooms/[id]/calculate-indexes.ts	Replaces strict plan-based permission checks with combined feature flag and plan conditions. Updates button rendering, permission validation, and dialog footer logic to check feature flag status or datarooms-plus plan eligibility. API endpoint now eagerly fetches team plan data and returns 403 if neither feature flag nor plan requirement is met.

Possibly related PRs

• fix: various fixes #1934: Modifies the same rebuild-index-button component's permission and gating logic, changing how feature flags versus plan checks control rendering and actions.

Pre-merge checks

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Title check	❓ Inconclusive	The title 'fix: dataroom index' is vague and generic. While it references 'dataroom index', it does not clearly convey what specific issue is being fixed or what the main change accomplishes.	Consider a more descriptive title that explains the fix, such as 'fix: enable dataroom index with feature flags and plan checks' or 'fix: combine feature flag and plan-based access for dataroom indexing'.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

components/datarooms/actions/rebuild-index-button.tsx (1)

39-47: Clear permission logic with intentional upsell funnel.

The boolean flags are well-defined with helpful comments. The logic creates an intentional UX funnel where:

• shouldShowButton: Shows button to feature flag users OR any datarooms plan holders
• canUseFeature: Allows usage only for feature flag users OR datarooms-plus plan holders

This means users with the base datarooms plan will see the button but receive an upgrade prompt when clicking. While this drives upgrades, consider if this creates confusion or if hiding the button entirely for non-plus users would provide better UX.

If you prefer to hide the button for users who cannot use the feature, simplify to:

-  // Show button if: feature flag is enabled OR user has datarooms plan or higher
-  const shouldShowButton = isDataroomIndexEnabled || hasDataroomsPlan;
-
-  // Allow usage if: feature flag is enabled OR user has datarooms-plus plan
-  const canUseFeature = isDataroomIndexEnabled || hasDataroomsPlusPlan;
+  // Show button and allow usage if: feature flag is enabled OR user has datarooms-plus plan
+  const shouldShowButton = isDataroomIndexEnabled || hasDataroomsPlusPlan;
+  const canUseFeature = shouldShowButton; // Same condition

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between cb1ebed and d6c9aaf.

📒 Files selected for processing (2)

• components/datarooms/actions/rebuild-index-button.tsx (3 hunks)
• pages/api/teams/[teamId]/datarooms/[id]/calculate-indexes.ts (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (2)

components/datarooms/actions/rebuild-index-button.tsx (2)

lib/hooks/use-feature-flags.ts (1)

• useFeatureFlags (10-31)

lib/swr/use-billing.ts (1)

• usePlan (86-136)

pages/api/teams/[teamId]/datarooms/[id]/calculate-indexes.ts (1)

lib/featureFlags/index.ts (1)

• getFeatureFlags (20-63)

🔇 Additional comments (5)

pages/api/teams/[teamId]/datarooms/[id]/calculate-indexes.ts (2)

43-65: LGTM! Efficient eager loading of team plan.

The query modification correctly adds team plan selection while maintaining proper user membership validation. The minimal select fields keep the query efficient.

---

71-81: Consistent permission logic with frontend; error handling already in place.

The combined feature flag and plan-based gating correctly implements OR logic that matches the frontend's canUseFeature check. The getFeatureFlags function already includes proper error handling with a try-catch block that gracefully degrades to default features on failure, preventing endpoint errors from propagating.

components/datarooms/actions/rebuild-index-button.tsx (3)

7-7: LGTM! Correct feature flag integration.

The useFeatureFlags hook is properly imported and used to check feature flag status.

Also applies to: 34-34

---

50-58: LGTM! Proper guard conditions.

The button rendering guard (line 50) and permission check (line 55) correctly use the new boolean flags, with a clear error message when the feature is not available.

---

142-161: LGTM! Appropriate upgrade flow.

The DialogFooter correctly uses canUseFeature to show either action buttons or an upgrade modal, providing a clear path for users to gain access to the feature.