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

Project	Deployment	Actions	Updated (UTC)
dub	Ready	Preview	Jun 12, 2026 6:50pm

No actionable comments were generated in the recent review. 🎉

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.

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

@coderabbitai full review. any breaking changes?

#!/bin/bash
echo "=== oauth authorize route ==="
cat apps/web/app/api/oauth/authorize/route.ts

echo ""
echo "=== authorize-form.tsx ==="
cat "apps/web/app/app.dub.co/(auth)/oauth/authorize/authorize-form.tsx"

echo ""
echo "=== page-client.tsx ==="
cat "apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/integrations/[integrationSlug]/page-client.tsx"

echo ""
echo "=== clientAccessCheck implementation ==="
rg -rn "clientAccessCheck" --type=ts --type=tsx -B2 -A15 | head -100

echo ""
echo "=== withWorkspace options/types ==="
rg -rn "requiredPermissions" --type=ts -B2 -A5 | head -80

echo ""
echo "=== integrations.write permission ==="
rg -rn "integrations.write" --type=ts -B2 -A2 | head -60

echo ""
echo "=== Authorize GET route (to check if it also needs protection) ==="
cat apps/web/app/api/oauth/authorize/route.ts 2>/dev/null | head -20

echo ""
echo "=== GET route check ==="
rg -rn "export const GET" apps/web/app/api/oauth/authorize/route.ts

echo ""
echo "=== Roles and permissions config ==="
rg -rn "\"integrations.write\"" --type=ts -B2 -A2 | head -60

echo ""
echo "=== billing viewer role constants ==="
rg -rn "billing|viewer" apps/web/lib/role-permissions.ts 2>/dev/null | head -40
fd "role" apps/web/lib --type=f | head -10

#!/bin/bash
echo "=== permissions.ts full ==="
cat apps/web/lib/api/rbac/permissions.ts

echo ""
echo "=== workspace-roles.ts ==="
cat apps/web/lib/workspace-roles.ts

echo ""
echo "=== clientAccessCheck full implementation ==="
fd "client-access-check" --type=f | xargs cat

echo ""
echo "=== withWorkspace WorkspaceOptions type ==="
rg -n "requiredPermissions" apps/web/lib/auth --type=ts -B2 -A5

echo ""
echo "=== scopes for role function ==="
rg -n "getScopesForRole" apps/web/lib/api/tokens/scopes.ts -A20

echo ""
echo "=== does the Authorize button also have the workspaceUnresolvedMessage in disabled? ==="
rg -n "workspaceUnresolvedMessage" "apps/web/app/app.dub.co/(auth)/oauth/authorize/authorize-form.tsx"

echo ""
echo "=== getIntegrationInstallUrl action - check for permissions ==="
fd "get-integration-install-url" --type=f | xargs cat 2>/dev/null

echo ""
echo "=== installAppsFlyerAction - check for permissions ==="
fd "install.ts" apps/web/lib/integrations/appsflyer --type=f | xargs cat 2>/dev/null

@pepeladeira Here's the full review of PR #4008.

Summary

The PR adds both server-side (withWorkspace) and client-side (clientAccessCheck) enforcement of integrations.write permission, which is only granted to owner and member roles. billing and viewer roles will now be blocked from authorizing integrations via the OAuth flow.

Breaking Changes

Yes — intentional and expected:

This is the intended behavior. No owner/member workflows are disrupted.

Issues Found

🔴 Permission Enforcement Gap — installAppsFlyerAction

The apps/web/lib/integrations/appsflyer/install.ts server action only checks the plan, not the role:

// Only checks plan — no role/permission check
if (!getPlanCapabilities(workspace.plan).canInstallAdvancedIntegrations) {
  throw new Error("AppsFlyer integration is only available on Advanced and Enterprise plans.");
}

A billing or viewer user on an Advanced plan could bypass the UI and call this server action directly to install AppsFlyer. The getIntegrationInstallUrl action (for Slack/HubSpot) already has a role guard via throwIfNoPermission. AppsFlyer needs the same treatment:

import { throwIfNoPermission } from "`@/lib/actions/throw-if-no-permission`";

// Add after workspace is available from ctx:
throwIfNoPermission({
  role: workspace.role,
  requiredRoles: ["owner", "member"],
});

🟡 Inconsistent Permission Enforcement Pattern

getIntegrationInstallUrl uses a direct role check (requiredRoles: ["owner", "member"]) rather than the permission-based approach (integrations.write) used everywhere else in this PR. Consider aligning it to use throwIfNoPermission with the permission action for consistency and future-proofing.

🟢 Logic is Correct

• authorize-form.tsx: The useMemo correctly short-circuits when !selectedWorkspace or while workspaces are loading. The disabled + disabledTooltip logic covers all states properly.
• page-client.tsx: The disabledTooltip fallback chain (plan gate → permissionsError → undefined) is correct for both "Enable" and "Remove" buttons.
• clientAccessCheck returns error: false (not undefined) when allowed — !!permissionsError handles this correctly in all call sites.
• API route: requiredPermissions: ["integrations.write"] on the POST handler is the right layer to enforce this server-side.

TL;DR — The core change is solid with no unintended regressions for existing owner/member users. The main gap to address is installAppsFlyerAction missing the role permission check.