Reviewing files that changed from the base of the PR and between 6ef200f and cb78304.

• apps/web/app/api/folders/[folderId]/users/route.ts (2 hunks)
• apps/web/app/api/folders/count/route.ts (2 hunks)
• apps/web/app/api/folders/permissions/route.ts (1 hunks)
• apps/web/lib/folder/get-folders.ts (2 hunks)
• apps/web/lib/folder/permissions.ts (3 hunks)
• apps/web/lib/types.ts (1 hunks)
• apps/web/ui/folders/edit-folder-panel.tsx (3 hunks)

apps/web/lib/folder/permissions.ts (1)

5-10: Workspace owner role lookup correctly feeds permission resolution

Importing Project, FolderUserRole, and WorkspaceRole and then fetching workspaceUser.role via projectUsers.findUniqueOrThrow and passing it into findUserFolderRole gives verifyFolderAccess the context it needs to treat workspace owners as folder owners. This aligns with the PR goal without changing behavior for non‑owners.

Also applies to: 44-60

apps/web/app/api/folders/permissions/route.ts (1)

28-37: Propagating workspaceRole into findUserFolderRole matches owner semantics

Passing workspaceRole: workspace.users[0]?.role into findUserFolderRole ensures workspace owners are surfaced as folder owners in this permissions listing, consistent with the new backend logic. This looks correct as long as withWorkspace guarantees that workspace.users[0] corresponds to the current member.

apps/web/lib/types.ts (1)

521-524: Extending FolderUser with workspaceRole keeps API and UI in sync

Adding workspaceRole: WorkspaceRole to FolderUser aligns the shared type with the updated /folders/[folderId]/users response and the folder‑editing UI, and it makes workspace ownership explicit wherever folder users are handled. TypeScript should help surface any remaining call sites that construct FolderUser without this field.

Reviewing files that changed from the base of the PR and between dd70169 and f2a202f.

• .github/workflows/e2e.yaml (1 hunks)
• apps/web/app/(ee)/api/cron/links/export/route.ts (4 hunks)
• apps/web/app/(ee)/api/events/route.ts (2 hunks)
• apps/web/app/api/analytics/export/route.ts (1 hunks)
• apps/web/app/api/folders/[folderId]/users/route.ts (3 hunks)
• apps/web/app/api/links/bulk/route.ts (4 hunks)
• apps/web/app/api/links/export/route.ts (3 hunks)
• apps/web/app/api/links/route.ts (3 hunks)
• apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/campaigns/campaigns-table.tsx (1 hunks)
• apps/web/lib/actions/folders/request-folder-edit-access.ts (2 hunks)
• apps/web/lib/api/links/process-link.ts (1 hunks)
• apps/web/lib/api/links/validate-links-query-filters.ts (2 hunks)
• apps/web/lib/constants/misc.ts (1 hunks)
• apps/web/lib/folder/permissions.ts (4 hunks)
• apps/web/lib/swr/use-workspace.ts (2 hunks)
• apps/web/tests/links/folder-link-access.test.ts (3 hunks)
• apps/web/tests/utils/env.ts (1 hunks)
• apps/web/tests/utils/integration-member.ts (1 hunks)
• apps/web/tests/utils/resource.ts (2 hunks)

• apps/web/app/api/links/bulk/route.ts

• GitHub Check: build

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/campaigns/campaigns-table.tsx (1)

200-202: The help article URL is valid and accessible.

The URL "https://dub.co/help/article/email-campaigns" returns a 200 response and is properly configured. The change is syntactically correct and functional.

apps/web/lib/actions/folders/request-folder-edit-access.ts (1)

46-59: LGTM! Efficient optimization.

Including the folder data in the create query eliminates the need for a separate fetch, reducing round-trips to the database. The selected fields (name and id) are exactly what's needed for the email notification downstream.

.github/workflows/e2e.yaml (1)

38-38: LGTM!

The addition of E2E_TOKEN_MEMBER follows the established pattern for test authentication tokens and properly uses GitHub secrets.

apps/web/tests/utils/env.ts (1)

6-6: LGTM!

The environment variable validation for E2E_TOKEN_MEMBER is correctly added and consistent with the existing token validations.

apps/web/tests/links/folder-link-access.test.ts (2)

2-2: LGTM!

The switch to IntegrationHarnessMember is appropriate for testing member-specific folder access permissions.

Also applies to: 17-17

---

308-313: Error messages correctly aligned.

Verification confirms the error messages in the test expectations match the backend bulk update endpoint exactly. Both the test file and the backend route handler use the identical message format: You don't have permission to update links in this folder: ${folderId}.

apps/web/tests/utils/resource.ts (2)

2-2: LGTM!

The addition of E2E_USER_ID_MEMBER with a descriptive comment clearly identifies this constant's purpose for member user tests.

---

36-38: Verify updated test resource IDs exist in the test environment.

Multiple test resource IDs have been updated (E2E_NO_ACCESS_FOLDER_ID, E2E_READ_ONLY_FOLDER_LINK_ID, E2E_NO_ACCESS_FOLDER_LINK_ID). If these reference actual database records in the test environment, ensure:

1. These IDs exist and are properly seeded
2. They have the correct access permissions configured
3. The links are associated with the correct folders

Mismatched IDs could cause test failures that are difficult to debug.

apps/web/tests/utils/integration-member.ts (4)

1-12: LGTM!

The imports and Resources interface are well-structured and provide clear type definitions for the test harness.

---

22-32: LGTM!

The constructor properly initializes the HTTP client with member-specific authentication using E2E_TOKEN_MEMBER.

---

34-59: Verify hardcoded workspace details match the test environment.

The init() method uses hardcoded values for the workspace (slug: "acme", name: "Acme, Inc."). Ensure these match the actual workspace associated with E2E_WORKSPACE_ID in the test environment to avoid confusion during debugging.

---

62-69: LGTM!

The deleteLink() helper method is well-implemented and provides necessary cleanup functionality for test scenarios.

apps/web/lib/constants/misc.ts (1)

3-3: LGTM! Good refactor to eliminate magic numbers.

Extracting the workspace links threshold into a named constant improves maintainability and makes the code more self-documenting.

apps/web/lib/swr/use-workspace.ts (1)

5-5: LGTM! Consistent use of the centralized constant.

Replacing the hard-coded threshold with MEGA_WORKSPACE_LINKS_LIMIT maintains consistency across the codebase.

Also applies to: 41-42

apps/web/lib/api/links/validate-links-query-filters.ts (2)

11-11: Good: Workspace type extended to support role-based access checks.

Adding "users" to the workspace type enables the function to pass workspace role information to verifyFolderAccess, which aligns with the PR objective of granting workspace owners full folder permissions.

---

36-42: Breaking change verified—all callers properly updated.

Verification confirms that validateLinksQueryFilters returns only { folderIds } and all four callers in the codebase have been updated to destructure folderIds accordingly:

• apps/web/app/api/links/route.ts:24
• apps/web/app/api/links/export/route.ts:25
• apps/web/app/api/links/count/route.ts:12
• apps/web/app/(ee)/api/cron/links/export/route.ts:76

No other callers exist, and no code attempts to destructure the removed selectedFolder property.

apps/web/app/(ee)/api/events/route.ts (2)

10-10: LGTM! Removed unused import.

The Folder type is no longer needed since the code no longer captures the folder object from verifyFolderAccess.

---

51-56: LGTM! Simplified folder access verification.

The code now uses verifyFolderAccess for permission checking only, without capturing the folder object. This aligns with the updated function signature and is cleaner.

apps/web/app/api/links/export/route.ts (1)

65-66: Verify that workspace.totalLinks is available from the withWorkspace HOF.

Similar to the concern in apps/web/app/api/links/route.ts, this code relies on workspace.totalLinks being available from the withWorkspace higher-order function. Ensure that the workspace object includes the totalLinks property.

See the verification script in the review comment for apps/web/app/api/links/route.ts (lines 34-35) to check the withWorkspace implementation.

apps/web/app/api/links/route.ts (1)

34-35: ****

The original concern is unfounded. workspace.totalLinks is properly available from the withWorkspace higher-order function. The Prisma schema defines totalLinks as a field on the Project model (defaulting to 0), and since withWorkspace calls prisma.project.findUnique without an explicit select clause, all project fields—including totalLinks—are returned by default. The code change is correct as written.

Likely an incorrect or invalid review comment.

apps/web/app/(ee)/api/cron/links/export/route.ts (1)

66-66: Semantic shift from folder-level to workspace-level search mode is intentional and consistent with codebase patterns.

The changes verified:

• Previous code (commit 82ac5d3): Used selectedFolder?.type === "mega" to determine exact search mode
• Current code: Uses workspace.totalLinks > MEGA_WORKSPACE_LINKS_LIMIT instead

This shift is intentional and aligns with how "mega workspace" detection is implemented throughout the codebase:

• use-workspace.ts:42: isMegaWorkspace: workspace && workspace.totalLinks > MEGA_WORKSPACE_LINKS_LIMIT
• api/links/route.ts:35: Uses the same workspace-level threshold for searchMode
• api/links/export/route.ts:66: Uses the same pattern

The refactoring standardizes on workspace-level mega detection rather than per-folder granularity, which is a deliberate design decision implemented consistently across all links/export endpoints.

apps/web/lib/folder/permissions.ts (1)

99-118: LGTM: Owner override correctly implemented for bulk checks.

The owner check in checkFolderPermissions correctly short-circuits folder permission lookups for workspace owners, consistent with the verifyFolderAccess function. The bulk permission check logic is sound.

Reviewing files that changed from the base of the PR and between f2a202f and 2aff587.

• apps/web/app/(ee)/api/cron/import/csv/route.ts (1 hunks)
• apps/web/app/(ee)/api/embed/referrals/links/[linkId]/route.ts (1 hunks)
• apps/web/app/(ee)/api/embed/referrals/links/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/links/[linkId]/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/links/route.ts (1 hunks)
• apps/web/lib/api/links/process-link.ts (2 hunks)
• apps/web/lib/api/links/utils/key-checks.ts (2 hunks)
• apps/web/lib/api/partners/generate-partner-link.ts (1 hunks)

• GitHub Check: build

apps/web/app/(ee)/api/partner-profile/programs/[programId]/links/route.ts (1)

119-128: LGTM! Owner role is appropriate for partner link creation.

The hard-coded owner role at line 122 is correct for partner link creation because:

• Partners create links on behalf of the workspace
• skipFolderChecks: true (line 125) already bypasses folder permission validation
• The owner role ensures the link can be placed in the program's default folder without access restrictions

The TODO at line 124 appears to acknowledge this distinction between the partner user and workspace owner, which is working as intended.

apps/web/app/(ee)/api/embed/referrals/links/route.ts (1)

107-116: LGTM! Owner role correctly applied for referral link creation.

The hard-coded owner role is appropriate here because referral links are created on behalf of the workspace, and folder permission checks are explicitly skipped (line 113). This ensures partners can create referral links without being constrained by folder access restrictions.

apps/web/app/(ee)/api/partner-profile/programs/[programId]/links/[linkId]/route.ts (1)

126-136: LGTM! Consistent with partner link creation.

The owner role is correctly applied for partner link updates, maintaining consistency with the POST route. This ensures partners can update links without folder permission constraints, which is appropriate for partner-managed links.

apps/web/app/(ee)/api/embed/referrals/links/[linkId]/route.ts (1)

76-86: LGTM! Owner role correctly applied for referral link updates.

The hard-coded owner role maintains consistency with the referral link creation route and appropriately bypasses folder permissions for partner-managed links.

Note: The @ts-expect-error at line 70 appears to be pre-existing and is not introduced by this PR.

apps/web/lib/api/links/utils/key-checks.ts (1)

10-19: LGTM! Type refactored to use Prisma's Project type.

The workspace parameter type is updated from Pick<WorkspaceProps, "plan"> to Pick<Project, "plan">, aligning with the Prisma client types used throughout the codebase. This is a type-only change with no functional impact.

apps/web/lib/api/links/process-link.ts (3)

5-7: LGTM! Type imports updated for workspace role support.

The imports are correctly updated to remove WorkspaceProps and add Project and WorkspaceRole from the Prisma client, supporting the new workspace type signature.

---

404-409: Verified: verifyFolderAccess properly utilizes workspace role information.

The function checks workspace.users[0]?.role === WorkspaceRole.owner at line 24-26 and grants workspace owners full control over all folders. The workspace object parameter includes the users array with role information, and the function correctly prioritizes workspace owner permissions before checking folder-level permissions.

---

35-37: Hard-coded workspace roles in CSV/referral flows are intentional for special flow types.

After verification:

1. Workspace roles ARE validated upstream: The withWorkspace middleware queries the actual user's role for each workspace (select: { role: true } where userId: session.user.id). Main API routes enforce this with requiredPermissions: ["links.read"].

2. Hard-coded owner roles are intentional:

   • CSV import (/api/cron/import/csv) is a QStash-protected internal cron job, not user-facing
   • Referral embed (/api/embed/referrals/links) uses withReferralsEmbedToken, a separate embed auth mechanism for partners
   • Partner API routes (/api/partners/links) pass actual workspace from middleware, no hard-code

3. Regular API link operations already pass actual user roles: The main API routes use withWorkspace middleware which populates workspace.users with the authenticated user's actual role before calling processLink.

The design is sound: authentication happens at route/middleware level, and processLink is not responsible for role validation. Hard-coded roles in special flows (cron/embed) are acceptable given their separate upstream auth mechanisms.

Reviewing files that changed from the base of the PR and between 2aff587 and a18eb4d.

• apps/web/app/api/folders/[folderId]/users/route.ts (4 hunks)
• apps/web/app/api/folders/permissions/route.ts (2 hunks)
• apps/web/app/api/links/bulk/route.ts (5 hunks)
• apps/web/lib/folder/permissions.ts (5 hunks)

• apps/web/app/api/links/bulk/route.ts
• apps/web/app/api/folders/[folderId]/users/route.ts

• GitHub Check: build

Reviewing files that changed from the base of the PR and between a18eb4d and aa8fdaf.

• apps/web/app/(ee)/api/cron/import/csv/route.ts (3 hunks)

apps/web/app/(ee)/api/cron/import/csv/route.ts (2)

7-7: Import removal is consistent with the refactor.

The WorkspaceProps import is no longer needed since the full Prisma workspace object is now passed to processLink instead of a manually constructed minimal object.

---

387-391: Add validation that the user is a workspace member and explicitly select required fields.

The query now fetches the importing user's actual workspace membership, which properly addresses the past security issue of hardcoded owner role. However, there are two concerns:

1. Missing membership validation: If the users array is empty (user not a member), workspace.users[0]?.role will be undefined in downstream code. This could cause unexpected behavior in permission checks. Add explicit validation after the query to ensure the user is a member of the workspace.

2. Implicit field selection: The users relation doesn't specify a select clause, relying on Prisma's default behavior to return all scalar fields. For clarity and to ensure the role field is explicitly included, specify the required fields.

Apply this diff to add validation and explicit field selection:

 const workspace = await prisma.project.findUniqueOrThrow({
   where: {
     id: workspaceId,
   },
   select: {
     id: true,
     plan: true,
     users: {
       where: {
         userId,
       },
+      select: {
+        role: true,
+      },
     },
   },
 });
+
+if (!workspace.users[0]) {
+  throw new Error(`User ${userId} is not a member of workspace ${workspaceId}`);
+}

Run the following script to verify that downstream permission checks properly handle the workspace structure:

Reviewing files that changed from the base of the PR and between aa8fdaf and 0f94836.

• apps/web/app/api/folders/[folderId]/route.ts (2 hunks)
• apps/web/lib/folder/permissions.ts (5 hunks)
• apps/web/ui/folders/folder-dropdown.tsx (1 hunks)

• GitHub Check: build

apps/web/ui/folders/folder-dropdown.tsx (1)

47-50: Removal of searchParams looks correct and behavior-neutral

searchParams was not used anywhere in this component, so narrowing the destructuring to { queryParams } is a safe cleanup and should just fix lint noise without affecting behavior.

Reviewing files that changed from the base of the PR and between 9e3e503 and 981bfc7.

• .github/workflows/e2e.yaml (1 hunks)
• apps/web/app/(ee)/api/cron/import/csv/route.ts (3 hunks)
• apps/web/app/(ee)/api/cron/links/export/route.ts (4 hunks)
• apps/web/app/(ee)/api/embed/referrals/links/[linkId]/route.ts (1 hunks)
• apps/web/app/(ee)/api/embed/referrals/links/route.ts (1 hunks)
• apps/web/app/(ee)/api/events/route.ts (2 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/links/[linkId]/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/links/route.ts (1 hunks)
• apps/web/app/api/analytics/export/route.ts (1 hunks)
• apps/web/app/api/folders/[folderId]/users/route.ts (4 hunks)
• apps/web/app/api/folders/count/route.ts (2 hunks)
• apps/web/app/api/folders/permissions/route.ts (2 hunks)
• apps/web/app/api/links/bulk/route.ts (5 hunks)
• apps/web/app/api/links/export/route.ts (3 hunks)
• apps/web/app/api/links/route.ts (3 hunks)
• apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/campaigns/campaigns-table.tsx (1 hunks)
• apps/web/lib/actions/folders/request-folder-edit-access.ts (2 hunks)
• apps/web/lib/api/links/process-link.ts (2 hunks)
• apps/web/lib/api/links/utils/key-checks.ts (2 hunks)
• apps/web/lib/api/links/validate-links-query-filters.ts (2 hunks)
• apps/web/lib/api/partners/generate-partner-link.ts (1 hunks)
• apps/web/lib/constants/misc.ts (1 hunks)
• apps/web/lib/folder/get-folders.ts (2 hunks)
• apps/web/lib/folder/permissions.ts (6 hunks)
• apps/web/lib/swr/use-workspace.ts (2 hunks)
• apps/web/lib/types.ts (1 hunks)
• apps/web/tests/links/folder-link-access.test.ts (3 hunks)
• apps/web/tests/utils/env.ts (1 hunks)
• apps/web/tests/utils/integration-member.ts (1 hunks)
• apps/web/tests/utils/resource.ts (2 hunks)
• apps/web/ui/folders/edit-folder-panel.tsx (3 hunks)
• apps/web/ui/folders/folder-dropdown.tsx (1 hunks)

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/campaigns/campaigns-table.tsx (1)

200-203: Copy/link update for learnMoreHref looks good

Using the help article URL when no filters are applied keeps behavior consistent with the unfiltered empty state (and avoids showing a "learn more" link for filtered-empty cases). No functional or UX regressions spotted.

apps/web/ui/folders/folder-dropdown.tsx (1)

49-49: LGTM: Unused variable cleanup.

Removing the unused searchParams variable is a clean refactor with no behavioral impact.

apps/web/lib/constants/misc.ts (1)

3-3: LGTM: Centralized constant for workspace link limits.

Extracting the hardcoded 1_000_000 threshold into a named constant improves maintainability and makes the intent clearer across the codebase.

apps/web/app/(ee)/api/events/route.ts (2)

10-10: LGTM: Removed unused import.

The Folder type is no longer needed since verifyFolderAccess no longer returns folder data.

---

51-56: The review comment's premise is incorrect.

The comment claims "removal of the captured folder variable aligns with the broader refactoring where verifyFolderAccess now focuses solely on verification rather than data retrieval." However, verification shows that verifyFolderAccess still returns folder data and is captured in other parts of the codebase:

• apps/web/app/api/folders/[folderId]/route.ts (line 17): const folder = await verifyFolderAccess({...}) captures the return value
• apps/web/app/api/folders/[folderId]/route.ts (line 23): return NextResponse.json(FolderSchema.parse(folder)) uses that captured value

The code under review in apps/web/app/(ee)/api/events/route.ts is correct for its context (verification-only usage), but the review comment incorrectly characterizes a broader refactoring that hasn't been fully applied or is intentionally incomplete across the codebase.

Likely an incorrect or invalid review comment.

apps/web/lib/swr/use-workspace.ts (2)

5-5: LGTM: Using centralized constant.

Importing and using MEGA_WORKSPACE_LINKS_LIMIT instead of hardcoding the threshold improves consistency.

---

41-42: LGTM: Replaced hardcoded threshold with constant.

The refactor from the magic number 1_000_000 to MEGA_WORKSPACE_LINKS_LIMIT improves code maintainability and aligns with the centralized constant definition.

apps/web/lib/actions/folders/request-folder-edit-access.ts (2)

24-29: LGTM: Verification without data capture.

The refactor to call verifyFolderAccess without capturing its return value aligns with the updated signature where verification is separate from data retrieval.

---

46-59: LGTM: Folder data retrieved from create response.

Retrieving folder metadata via the include clause in the Prisma create call is a reasonable refactor that maintains the necessary data for email composition while aligning with the updated verifyFolderAccess behavior.

apps/web/lib/folder/get-folders.ts (2)

36-62: LGTM: Owner bypass implements PR requirements correctly.

The conditional logic properly grants workspace owners access to all folders by skipping the access filter when workspaceUser?.role === WorkspaceRole.owner. The optional chaining handles the edge case where workspaceUser is null (user not in workspace), correctly applying filters in that scenario.

---

21-31: Database index properly optimizes the workspace user lookup—performance concern is mitigated.

The workspace user query executes efficiently against the @@unique([userId, projectId]) constraint on the ProjectUsers model (packages/prisma/schema/workspace.prisma:112), making the findUnique lookup O(1). This query was intentionally added in commit cb78304 to support role-based folder filtering for workspace owners. While called from multiple endpoints (API, webhook, analytics), the indexed lookup ensures minimal overhead per invocation.

apps/web/app/(ee)/api/partner-profile/programs/[programId]/links/route.ts (1)

122-122: Verify owner role assignment for partner link creation.

Similar to the PATCH endpoint, the POST endpoint grants owner-level permissions via users: [{ role: "owner" }] during partner link creation. Ensure this aligns with the intended permission model where partners operate with elevated privileges within their program context.

apps/web/app/(ee)/api/partner-profile/programs/[programId]/links/[linkId]/route.ts (1)

129-129: Owner role assignment is consistent across all partner and embed routes.

Verification confirms that users: [{ role: "owner" }] is the established pattern used throughout the partner and embed infrastructure. This same pattern appears in all partner profile link routes, embed referral routes, and the partner link generation utility. The TODO comment in generate-partner-link.ts indicates the team is aware of RBAC scope limitations and has planned improvements, but the current owner-level assignment is intentional and consistent.

apps/web/app/(ee)/api/embed/referrals/links/route.ts (1)

107-114: Owner role addition is correct but has limited impact due to skipFolderChecks.

The addition of users: [{ role: "owner" }] aligns with the PR's objective to propagate workspace roles through permission checks. However, since skipFolderChecks: true is set on line 113, folder permission checks are bypassed entirely in this flow, making the owner role less impactful here.

apps/web/app/(ee)/api/embed/referrals/links/[linkId]/route.ts (1)

76-84: Owner role addition is correct but has limited impact due to skipFolderChecks.

Similar to the POST handler, the addition of users: [{ role: "owner" }] is consistent with the PR's objectives, but skipFolderChecks: true on line 83 bypasses folder permission checks, reducing the practical impact of the owner role in this flow.

apps/web/app/api/folders/permissions/route.ts (2)

3-6: LGTM! Import rename reflects the updated function name.

The import has been correctly updated from findUserFolderRole to findFolderUserRole, aligning with the function rename in the permissions module.

---

33-43: LGTM! Workspace role is now correctly propagated to permission calculation.

The changes correctly:

1. Pass workspaceRole from the workspace context to findFolderUserRole
2. Use the more descriptive variable name userFolderRole
3. Feed the result into getFolderPermissions

According to past review comments, the underlying findFolderUserRole function was updated to return the internal role key (e.g., "owner") for workspace owners, which ensures they receive full folder permissions as intended by this PR.

apps/web/lib/api/partners/generate-partner-link.ts (1)

52-56: Owner role hardcoding is temporary; TODO flags future RBAC work.

The workspace payload now includes users: [{ role: "owner" }], consistent with changes across the codebase. The TODO comment on line 55 correctly identifies that full folders RBAC should be applied to generatePartnerLink checks in the future. For now, treating all partner link generation as owner-level operations is a reasonable interim approach.

apps/web/tests/utils/env.ts (1)

6-6: LGTM! Member token validation added consistently.

The addition of E2E_TOKEN_MEMBER to the schema is consistent with existing token validation patterns and is required for the new member-level integration test infrastructure.

.github/workflows/e2e.yaml (1)

38-38: Manual verification required: Cannot check GitHub secrets in sandbox environment.

The verification command requires access to the GitHub repository settings, which cannot be performed in this sandbox environment due to the absence of a git repository context.

To verify the secret exists, run this command in your local repository or CI environment:

gh secret list | grep -i E2E_TOKEN_MEMBER

If the secret is not found, configure E2E_TOKEN_MEMBER in your GitHub repository settings (Settings → Secrets and variables → Actions) before merging.

apps/web/app/api/links/route.ts (2)

7-7: Verify the threshold calibration through performance testing or design documentation.

The constant MEGA_WORKSPACE_LINKS_LIMIT = 1_000_000 is properly defined in apps/web/lib/constants/misc.ts and consistently used across four files to switch search mode from fuzzy to exact when a workspace exceeds 1 million links. However, no performance calibration data or tests exist in the codebase to validate this threshold value.

Confirm that:

• The 1 million threshold was determined through performance testing
• This threshold is optimal for your typical workspace sizes and search performance characteristics
• Consider documenting the rationale or performance data as a code comment

---

24-35: Review comment is based on incorrect premise about prior implementation.

The review describes a shift from per-folder search mode logic (selectedFolder?.isMegaFolder) to workspace-wide logic (workspace.totalLinks > MEGA_WORKSPACE_LINKS_LIMIT). However, git history shows that searchMode has been workspace-wide since its introduction in commit e4cdf5d—there was never per-folder logic to change from. The current implementation matches the original design.

Likely an incorrect or invalid review comment.

apps/web/lib/types.ts (1)

521-524: API contract verified - workspaceRole field properly populated in all FolderUser returns.

Verification confirms that the single API endpoint returning FolderUser[] objects (apps/web/app/api/folders/[folderId]/users/route.ts) correctly populates the workspaceRole field on all code paths:

• When no folder-specific user record exists (lines 63-68): includes workspaceRole
• When folder-specific user record exists (lines 78-84): includes workspaceRole

No other API routes return FolderUser objects. The breaking change is properly implemented.

apps/web/app/(ee)/api/cron/links/export/route.ts (1)

9-9: Workspace link-count–based searchMode looks consistent and safe

Selecting totalLinks on the workspace and deriving searchMode from workspace.totalLinks > MEGA_WORKSPACE_LINKS_LIMIT keeps the cron export in line with the main links export route and avoids depending on the previously inferred selectedFolder. The workspace null-check before use and continued use of validateLinksQueryFilters (now just folderIds) preserve correctness of the filters.

Also applies to: 58-68, 76-80, 93-107

apps/web/app/(ee)/api/cron/import/csv/route.ts (1)

7-7: CSV import now respects real workspace membership for folder checks

Fetching workspace with { id, plan, users: { where: { userId } } }, passing it directly into processLink, and typing the bulk insert as ProcessedLinkProps[] aligns this cron worker with the updated processLink contract and folder-permission helpers. This removes the prior hardcoded owner shortcut and ensures CSV imports honor the importing user’s actual role while still allowing owners to bypass folder-level restrictions as intended.

Also applies to: 380-393, 395-410, 424-430

apps/web/app/api/links/bulk/route.ts (1)

20-21: Consolidated bulk folder-permission checks are correct and consistent

Switching POST, PATCH, and DELETE bulk flows to use verifyFolderAccessBulk with { workspace, userId, folderIds, requiredPermission: "folders.links.write" } keeps permission evaluation consistent with the new folder-permissions API and properly applies workspace-owner shortcuts. The follow‑up filtering logic and the updated PATCH error copy (“update links in this folder”) remain aligned with the route’s behavior and the corresponding tests.

Also applies to: 169-214, 348-381, 525-543

apps/web/tests/utils/resource.ts (1)

2-2: Member user and folder/link fixture IDs updated appropriately

Defining E2E_USER_ID_MEMBER and refreshing the no-access folder and link IDs are straightforward test-fixture updates to support the new member harness and permission scenarios. Nothing here affects production behavior.

Also applies to: 36-38

apps/web/app/api/folders/count/route.ts (1)

4-5: Owner-aware folder count logic matches the permission model

Using workspace.users[0]?.role to gate the extra OR/users.none filters ensures that non‑owners still exclude folders where they have explicit “no access”, while workspace owners simply count all folders in the workspace (subject only to projectId and optional name search). This aligns the count endpoint with the new owner‑sees‑everything semantics.

Also applies to: 14-15, 19-39

apps/web/ui/folders/edit-folder-panel.tsx (1)

14-15: Folder role UI correctly treats workspace owners as immutable with a clear tooltip

Deriving isWorkspaceOwner from user.workspaceRole, folding it into disableRoleUpdate, and wrapping the role <select> in DynamicTooltipWrapper (with an owner-specific message) ensures workspace owners always appear with full access and cannot be edited via folder‑level roles. The logic for non‑owners remains unchanged and continues to use the existing server action flow.

Also applies to: 19-20, 252-256, 272-313

apps/web/lib/api/links/process-link.ts (1)

5-8: Updated workspace type for processLink aligns with new permission helpers

Narrowing the workspace parameter to id/plan plus a users array with role entries, and importing the corresponding Prisma types, matches how callers now construct workspace objects (e.g., CSV import and bulk routes) and lets downstream helpers like verifyFolderAccess infer owner status from workspace.users. The core link‑validation logic remains unchanged.

Also applies to: 34-37

apps/web/tests/links/folder-link-access.test.ts (1)

2-2: Member-focused harness and updated error expectations match the new bulk route behavior

Instantiating IntegrationHarnessMember aligns these folder-access tests with the member role they intend to cover, and the revised expectations for bulk PATCH errors (“You don't have permission to update links in this folder: …”) accurately reflect the updated messaging in /api/links/bulk. The rest of the permission scenarios remain intact.

Also applies to: 17-18, 308-314

apps/web/lib/api/links/utils/key-checks.ts (1)

10-10: LGTM: Type alignment with Prisma Client.

The change from WorkspaceProps to Project correctly aligns the type with Prisma's generated client types, maintaining consistency across the codebase.

Also applies to: 19-19

apps/web/lib/api/links/validate-links-query-filters.ts (2)

11-11: LGTM: Workspace type extended for role-based permission checks.

Adding the users array to the workspace type enables downstream permission logic to access workspace roles, which is essential for the owner permission shortcuts introduced in this PR.

---

36-41: LGTM: Simplified to side-effect validation.

The removal of selectedFolder from the return value simplifies the API contract. The verifyFolderAccess call now serves purely as a validation gate (throwing on access denial), which is clearer than capturing and returning folder metadata.

Also applies to: 65-67

apps/web/app/api/folders/[folderId]/users/route.ts (2)

3-3: LGTM: Function rename and signature properly updated.

The rename from findUserFolderRole to findFolderUserRole and the addition of the workspaceRole parameter correctly implement the owner permission logic introduced in this PR.

Also applies to: 72-76

---

51-51: LGTM: workspaceRole propagation implemented correctly.

The addition of folder: true to the query, the null-safe handling when folderUser is missing, and the inclusion of workspaceRole in all response objects properly support the workspace owner permission model.

Also applies to: 61-70, 84-84

apps/web/lib/folder/permissions.ts (3)

32-41: LGTM: Folder validation now occurs before owner shortcut.

The reordering to fetch and validate the folder (lines 32-36) before the owner permission check (lines 38-41) correctly addresses the critical security issue flagged in previous reviews. This ensures workspace owners can only access folders within their workspace.

---

136-158: LGTM: Role resolution logic correctly prioritizes workspace owner.

The findFolderUserRole function properly implements the three-tier resolution: workspace owner → explicit folder user role → folder access level mapping. The enum return values align with the permission lookup in getFolderPermissions.

---

161-167: LGTM: Null-safe permission lookup.

The getFolderPermissions function correctly handles null roles and returns an empty array for unmapped roles, providing safe fallback behavior.

apps/web/tests/utils/integration-member.ts (1)

1-70: LGTM: Well-structured test harness for member user scenarios.

The IntegrationHarnessMember class provides a clean abstraction for testing folder permission logic from a non-owner perspective. The structure parallels existing integration test patterns, which promotes consistency. The E2E_TOKEN_MEMBER secret is properly configured in CI (.github/workflows/e2e.yaml injects it from GitHub Secrets).

apps/web/app/api/links/export/route.ts (1)

9-9: LGTM: Verified that workspace.totalLinks is consistently populated by withWorkspace middleware.

The workspace query in workspace.ts uses include for the users relationship without an explicit select on the parent project model. This means all scalar fields (including totalLinks) are returned by default from Prisma. The field is already actively used throughout the codebase in multiple places without issues, confirming the change is sound.

Reviewing files that changed from the base of the PR and between 981bfc7 and 4b196ee.

• apps/web/app/api/folders/[folderId]/users/route.ts (3 hunks)
• apps/web/ui/folders/edit-folder-sheet.tsx (6 hunks)
• apps/web/ui/folders/folder-actions.tsx (2 hunks)
• apps/web/ui/modals/set-default-folder-modal.tsx (1 hunks)
• packages/ui/src/nav/content/resources-content.tsx (1 hunks)

• packages/ui/src/nav/content/resources-content.tsx

• apps/web/app/api/folders/[folderId]/users/route.ts

• GitHub Check: build

apps/web/ui/modals/set-default-folder-modal.tsx (1)

65-65: Documentation link verified and working correctly.

The updated href to the help article with anchor #setting-a-default-folder is accessible and the anchor exists on the target page. This improvement successfully directs users to the relevant documentation section.

apps/web/ui/folders/folder-actions.tsx (1)

24-24: LGTM! Clean rename from Panel to Sheet.

The import and hook usage have been correctly updated to use the new useEditFolderSheet API. The functionality remains unchanged.

Also applies to: 53-56

apps/web/ui/folders/edit-folder-sheet.tsx (3)

14-14: LGTM! Required imports added.

The WorkspaceRole and DynamicTooltipWrapper imports support the new workspace owner access control logic introduced in this PR.

Also applies to: 19-19

---

35-35: LGTM! Consistent Panel → Sheet terminology update.

All interfaces, components, and hooks have been systematically renamed from "Panel" to "Sheet". The changes are consistent with the updated usage in folder-actions.tsx.

Also applies to: 42-45, 219-225, 332-346

---

252-255: Verification complete—no issues found.

The FolderUser type in apps/web/lib/types.ts:521-523 correctly includes the workspaceRole: WorkspaceRole; property, and the API endpoint apps/web/app/api/folders/[folderId]/users/route.ts properly returns this field. The code at lines 252-255 in edit-folder-sheet.tsx is correctly typed and implements the workspace owner access control as intended.

Reviewing files that changed from the base of the PR and between 4b196ee and 486904c.

• apps/web/ui/folders/folder-info-panel.tsx (3 hunks)

• GitHub Check: Socket Security: Pull Request Alerts
• GitHub Check: build

apps/web/ui/folders/folder-info-panel.tsx (2)

7-7: LGTM! Import changes align with the refactored UserList.

The removal of Tooltip and addition of Avatar correctly reflects the change from tooltip-based hover display to a direct list layout.

---

75-75: LGTM! Consistent loading state propagation.

The isLoading prop is correctly passed to all three UserList instances, ensuring consistent loading behavior across owner, editor, and viewer sections.

Also applies to: 82-82, 89-89