packages/trpc/server/routers/viewer/pbac/_router.tsx (1)

18-47: LGTM! Enhanced permission string validation handles nested resources correctly.

The new validation logic properly addresses complex resource names using a longest-match strategy. The special case handling for ._resource and the sorted resource matching ensure accurate parsing of permission strings like "organization.attributes.read".

Consider caching the sorted resources array to avoid sorting on every validation:

+// Cache sorted resources outside the validation function
+const sortedResourceValues = Object.values(Resource).sort((a, b) => b.length - a.length);
+
 const permissionStringSchema = z.custom<PermissionString>((val) => {
   if (typeof val !== "string") return false;

   // Handle special case for _resource
   if (val.endsWith("._resource")) {
     return true;
   }

-  // Find the longest matching resource from the end
-  const resourceValues = Object.values(Resource);
   let matchedResource: string | null = null;
   let remainingAction: string | null = null;

-  // Sort resources by length (longest first) to match the most specific resource
-  const sortedResources = resourceValues.sort((a, b) => b.length - a.length);
-
-  for (const resource of sortedResources) {
+  for (const resource of sortedResourceValues) {

packages/features/pbac/infrastructure/repositories/RoleRepository.ts (1)

11-38: Excellent consistency with router validation logic.

The parsePermissionString helper function implements the same longest-match strategy as the router validation, ensuring consistent handling of complex permission strings throughout the system. The documentation is clear and the special case handling for ._resource is appropriate.

Consider caching the sorted resources array for performance, similar to the suggestion for the router:

+// Cache sorted resources outside the function
+const sortedResourceValues = Object.values(Resource).sort((a, b) => b.length - a.length);
+
 function parsePermissionString(permissionString: string): { resource: string; action: string } {
   // Handle special case for _resource
   if (permissionString.endsWith("._resource")) {
     const resource = permissionString.substring(0, permissionString.length - 10);
     return { resource, action: "_resource" };
   }

-  // Find the longest matching resource from the end
-  const resourceValues = Object.values(Resource);
-
-  // Sort resources by length (longest first) to match the most specific resource
-  const sortedResources = resourceValues.sort((a, b) => b.length - a.length);
-
-  for (const resource of sortedResources) {
+  for (const resource of sortedResourceValues) {

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Learnt from: sean-brydon
PR: calcom/cal.com#22618
File: packages/trpc/server/routers/viewer/eventTypes/utils/transformUtils.ts:113-113
Timestamp: 2025-08-05T07:42:06.335Z
Learning: In Cal.com's getUserEventGroups handler refactor (PR #22618), the membershipCount field for team event groups is intentionally set to 0 in the new createTeamEventGroup function, as confirmed by sean-brydon (PR author). This preserves the same behavior as the old implementation that was being refactored, maintaining backward compatibility. While other parts of the codebase may use actual member counts, this specific implementation maintains the previous behavior.

Learnt from: CR
PR: calcom/cal.com#0
File: .cursor/rules/review.mdc:0-0
Timestamp: 2025-07-28T11:50:23.946Z
Learning: Applies to **/*Repository.ts : Repository files must include `Repository` suffix, prefix with technology if applicable (e.g., `PrismaAppRepository.ts`), and use PascalCase matching the exported class

Learnt from: Anshumancanrock
PR: calcom/cal.com#22570
File: apps/web/modules/signup-view.tsx:253-253
Timestamp: 2025-07-21T21:33:23.371Z
Learning: In signup-view.tsx, when checking if redirectUrl contains certain strings, using explicit && checks (redirectUrl && redirectUrl.includes()) is preferred over optional chaining (redirectUrl?.includes()) to ensure the result is always a boolean rather than potentially undefined. This approach provides cleaner boolean contracts for downstream conditional logic.

packages/trpc/server/routers/viewer/eventTypes/utils/EventTypeGroupFilter.ts (1)

32-44: Consider extracting permission mapping to improve maintainability.

The switch statement maps permission strings to permission fields, but this creates a tight coupling between the permission strings and the TeamPermissions interface structure.

Consider extracting this mapping to a separate utility function or configuration:

+const PERMISSION_MAPPING = {
+  "eventType.read": () => true,
+  "eventType.create": (permissions: TeamPermissions) => permissions.canCreate,
+  "eventType.update": (permissions: TeamPermissions) => permissions.canEdit,
+  "eventType.delete": (permissions: TeamPermissions) => permissions.canDelete,
+} as const;

-      switch (permission) {
-        case "eventType.read":
-          // All groups with permissions can read
-          return true;
-        case "eventType.create":
-          return permissions.canCreate;
-        case "eventType.update":
-          return permissions.canEdit;
-        case "eventType.delete":
-          return permissions.canDelete;
-        default:
-          return false;
-      }
+      const permissionCheck = PERMISSION_MAPPING[permission];
+      return permissionCheck ? permissionCheck(permissions) : false;

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Learnt from: sean-brydon
PR: calcom/cal.com#22618
File: packages/trpc/server/routers/viewer/eventTypes/utils/transformUtils.ts:113-113
Timestamp: 2025-08-05T07:42:06.335Z
Learning: In Cal.com's getUserEventGroups handler refactor (PR #22618), the membershipCount field for team event groups is intentionally set to 0 in the new createTeamEventGroup function, as confirmed by sean-brydon (PR author). This preserves the same behavior as the old implementation that was being refactored, maintaining backward compatibility. While other parts of the codebase may use actual member counts, this specific implementation maintains the previous behavior.

Learnt from: sean-brydon
PR: calcom/cal.com#22618
File: packages/trpc/server/routers/viewer/eventTypes/utils/transformUtils.ts:113-113
Timestamp: 2025-08-05T07:42:06.335Z
Learning: In Cal.com's getUserEventGroups handler refactor (PR #22618), the membershipCount field for team event groups is intentionally set to 0 in the new createTeamEventGroup function, as confirmed by sean-brydon (PR author). This preserves the same behavior as the old implementation that was being refactored, maintaining backward compatibility. While other parts of the codebase may use actual member counts, this specific implementation maintains the previous behavior.

Learnt from: sean-brydon
PR: calcom/cal.com#22618
File: packages/trpc/server/routers/viewer/eventTypes/utils/transformUtils.ts:113-113
Timestamp: 2025-08-05T07:42:06.335Z
Learning: In Cal.com's event type system, the membershipCount field for team event groups is intentionally set to 0, as confirmed by sean-brydon (PR author). This behavior was preserved during the refactor from the old getUserEventGroups.handler.ts implementation to the new createTeamEventGroup function in transformUtils.ts. This is not a bug but the intended behavior that maintains consistency with the previous implementation.

Learnt from: sean-brydon
PR: calcom/cal.com#22618
File: packages/trpc/server/routers/viewer/eventTypes/utils/transformUtils.ts:113-113
Timestamp: 2025-08-05T07:42:06.335Z
Learning: In Cal.com's event type system, the membershipCount field for team event groups is intentionally hard-coded to 0, as confirmed by sean-brydon. This behavior was preserved during the refactor from the old getUserEventGroups.handler.ts implementation to the new createTeamEventGroup function in transformUtils.ts. This is not a bug but the intended behavior.

packages/trpc/server/routers/viewer/eventTypes/utils/EventTypeGroupFilter.test.ts (1)

163-166: Remove leftover diff markers and duplicate declaration; use the correct permission key.

You have committed diff artifacts here (lines starting with "-" and "+"). This causes the Biome parse errors and the duplicate result declaration flagged in static analysis. Also, the old permission "eventType.edit" must be replaced with the standardized "eventType.update".

Apply this fix:

-      const result = filterEvents(allGroups, mockPermissionsMap).has("eventType.edit").readOnly(false).get();
-      const result = filterEvents(allGroups, mockPermissionsMap).has("eventType.update").readOnly(false).get();
+      const result = filterEvents(allGroups, mockPermissionsMap)
+        .has("eventType.update")
+        .readOnly(false)
+        .get();

Run this quick check to ensure no other stray diff markers made it into source files:

#!/bin/bash
# Search for lines that start with a lone '+' or '-' followed by a space (common leftover from diffs)
rg -n '^[[:space:]]*[+-][[:space:]]+[^/*+-]' --glob '!**/node_modules/**'

Expected: no matches. If matches appear in this test file, remove the offending lines.

packages/trpc/server/routers/viewer/eventTypes/utils/EventTypeGroupFilter.test.ts (1)

35-36: Align team mocks’ membershipCount with intended semantics (0).

Per the retrieved learnings for this PR, team event groups intentionally report membershipCount: 0 to preserve legacy behavior. While these tests don’t assert on membershipCount, aligning the mocks avoids confusion and reduces accidental reliance later.

   metadata: {
-      membershipCount: 5,
+      membershipCount: 0,
       readOnly: false,
   },
...
   metadata: {
-      membershipCount: 3,
+      membershipCount: 0,
       readOnly: true,
   },

Also applies to: 50-51

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Learnt from: sean-brydon
PR: calcom/cal.com#22618
File: packages/trpc/server/routers/viewer/eventTypes/utils/transformUtils.ts:113-113
Timestamp: 2025-08-05T07:42:06.335Z
Learning: In Cal.com's getUserEventGroups handler refactor (PR #22618), the membershipCount field for team event groups is intentionally set to 0 in the new createTeamEventGroup function, as confirmed by sean-brydon (PR author). This preserves the same behavior as the old implementation that was being refactored, maintaining backward compatibility. While other parts of the codebase may use actual member counts, this specific implementation maintains the previous behavior.

Learnt from: sean-brydon
PR: calcom/cal.com#22618
File: packages/trpc/server/routers/viewer/eventTypes/utils/transformUtils.ts:113-113
Timestamp: 2025-08-05T07:42:06.335Z
Learning: In Cal.com's getUserEventGroups handler refactor (PR #22618), the membershipCount field for team event groups is intentionally set to 0 in the new createTeamEventGroup function, as confirmed by sean-brydon (PR author). This preserves the same behavior as the old implementation that was being refactored, maintaining backward compatibility. While other parts of the codebase may use actual member counts, this specific implementation maintains the previous behavior.

Learnt from: sean-brydon
PR: calcom/cal.com#22618
File: packages/trpc/server/routers/viewer/eventTypes/utils/transformUtils.ts:113-113
Timestamp: 2025-08-05T07:42:06.335Z
Learning: In Cal.com's event type system, the membershipCount field for team event groups is intentionally set to 0, as confirmed by sean-brydon (PR author). This behavior was preserved during the refactor from the old getUserEventGroups.handler.ts implementation to the new createTeamEventGroup function in transformUtils.ts. This is not a bug but the intended behavior that maintains consistency with the previous implementation.

Learnt from: din-prajapati
PR: calcom/cal.com#21854
File: packages/app-store/office365calendar/__tests__/unit_tests/SubscriptionManager.test.ts:0-0
Timestamp: 2025-08-05T12:04:29.037Z
Learning: In packages/app-store/office365calendar/lib/CalendarService.ts, the fetcher method in Office365CalendarService class is public, not private. It was specifically changed from private to public in this PR to support proper testing and external access patterns.

Learnt from: Anshumancanrock
PR: calcom/cal.com#22570
File: apps/web/modules/signup-view.tsx:253-253
Timestamp: 2025-07-21T21:33:23.371Z
Learning: In signup-view.tsx, when checking if redirectUrl contains certain strings, using explicit && checks (redirectUrl && redirectUrl.includes()) is preferred over optional chaining (redirectUrl?.includes()) to ensure the result is always a boolean rather than potentially undefined. This approach provides cleaner boolean contracts for downstream conditional logic.

Learnt from: sean-brydon
PR: calcom/cal.com#22618
File: packages/trpc/server/routers/viewer/eventTypes/utils/transformUtils.ts:113-113
Timestamp: 2025-08-05T07:42:06.335Z
Learning: In Cal.com's event type system, the membershipCount field for team event groups is intentionally hard-coded to 0, as confirmed by sean-brydon. This behavior was preserved during the refactor from the old getUserEventGroups.handler.ts implementation to the new createTeamEventGroup function in transformUtils.ts. This is not a bug but the intended behavior.

packages/trpc/server/routers/viewer/workflows/activateEventType.handler.ts (1)

98-112: Reuse PermissionCheckService and refine permission scope & error code

Great job enforcing PBAC for team event types and correctly using the authenticated user’s ID rather than an input parameter. A few optional refinements:

• Module-level service instance
Move new PermissionCheckService() out of the handler and reuse a single instance:

// At the top of activateEventType.handler.ts
const permissionCheckService = new PermissionCheckService();

   if (eventType.teamId) {
-    const permissionCheckService = new PermissionCheckService();
     const hasPermissionToActivate = await permissionCheckService.checkPermission({
       userId: ctx.user.id,
       teamId: eventType.teamId,
       permission: "eventType.update",
       fallbackRoles: [MembershipRole.ADMIN, MembershipRole.OWNER],
     });

• Permission scope (optional least-privilege)
Since we have a workflow.update permission defined for workflows, you could switch to that for toggling workflow activation:

       // permission: "eventType.update",
-      permission: "eventType.update",
+      permission: "workflow.update",

If you’d rather keep "eventType.update" for now, plan a follow-up when a more granular workflow-scoped permission ships.

• Error code consistency (optional)
For authenticated users lacking rights, you might use TRPCError({ code: "FORBIDDEN" }) to distinguish “not allowed” from “not authenticated.” If consistency with existing handlers is more important, retaining "UNAUTHORIZED" is fine.

packages/trpc/server/routers/viewer/workflows/getAllActiveWorkflows.handler.ts (2)

40-40: Consider injecting/reusing PermissionCheckService

Constructing PermissionCheckService per request is fine; however, consider one of:

• Inject via ctx for easier testing/mocking.
• Reuse a shared instance if the service is stateless (it appears to be), to avoid repeated instantiation overhead.

Optional, not blocking.

---

43-51: Do authorization checks before fetching workflows

Currently, workflows are fetched (Lines 20-27) before permission checks, then discarded on UNAUTHORIZED. This adds DB load and increases risk of accidental data leakage via logs/metrics. Recommend moving the workflow fetch until after the authorization block completes. See unified refactor in the next comment’s diff.

Please confirm there’s no intentional side-effect from getEventTypeWorkflows that you rely on before auth.

packages/trpc/server/routers/viewer/workflows/list.handler.ts (4)

6-6: ctx.prisma is typed but never used; adopt it or remove it

We’re importing the PrismaClient type and declaring ctx.prisma but still using the global prisma import. Prefer the request-scoped client from ctx to enable per-request transactions, tracing, and easier testing; otherwise drop the unused ctx.prisma from types.

Option A (recommended): switch to ctx.prisma

-import { prisma } from "@calcom/prisma";
-import type { PrismaClient } from "@calcom/prisma";
+// Use request-scoped Prisma from ctx for better tx scoping and testability
+import type { PrismaClient } from "@calcom/prisma";
@@
 export const listHandler = async ({ ctx, input }: ListOptions) => {
+  const prisma = ctx.prisma;

Option B (minimal): remove ctx.prisma from types if sticking with global prisma

-import type { PrismaClient } from "@calcom/prisma";
@@
 type ListOptions = {
   ctx: {
     user: NonNullable<TrpcSessionUser>;
-    prisma: PrismaClient;
   };
   input: TListInputSchema;
 };

Also applies to: 15-16

---

103-106: Avoid duplicating readOnly logic; rely on WorkflowPermissionsBuilder

You precompute readOnly for org (force true) and for team/all branches by inspecting team.members. addPermissionsToWorkflows already returns readOnly, so this duplication creates potential drift and extra DB payload (members).

Prefer to drop local readOnly and rely solely on the builder’s value. Keep isOrg tagging if the UI needs it.

@@
-    workflows.push(
-      ...activeOrgWorkflows.map((workflow) => {
-        return { ...workflow, isOrg: true, readOnly: true };
-      })
-    );
+    workflows.push(...activeOrgWorkflows.map((workflow) => ({ ...workflow, isOrg: true })));
@@
-    const workflowsWithReadOnly = teamWorkflows.map((workflow) => {
-      const readOnly = !!workflow.team?.members?.find(
-        (member) => member.userId === ctx.user.id && member.role === MembershipRole.MEMBER
-      );
-      return { ...workflow, readOnly };
-    });
-
-    workflows.push(...workflowsWithReadOnly);
+    workflows.push(...teamWorkflows);
@@
-  const workflowsWithReadOnly: WorkflowType[] = allWorkflows.map((workflow) => {
-    const readOnly = !!workflow.team?.members?.find(
-      (member) => member.userId === ctx.user.id && member.role === MembershipRole.MEMBER
-    );
-
-    return { readOnly, ...workflow };
-  });
-
-  workflows.push(...workflowsWithReadOnly);
+  workflows.push(...allWorkflows);

Benefits:

• Less data fetched (you can drop team.members from selects).
• Single source of truth for readOnly.

Also applies to: 153-160, 267-273

---

162-169: Minor: remove repetition by extracting an augment-and-filter helper

The same addPermissionsToWorkflows + filter chain appears in three places. Extracting a small helper keeps the handler focused and reduces mistakes.

async function augmentAndFilter<T extends { id: number; teamId: number | null; userId: number | null }>(
  items: T[],
  currentUserId: number
) {
  const withPerms = await addPermissionsToWorkflows(items, currentUserId);
  return withPerms.filter((w) => w.permissions.canView);
}

// Usage:
// const filteredWorkflows = await augmentAndFilter(workflows, ctx.user.id);
// return { workflows: filteredWorkflows };

Also applies to: 210-217, 277-284

---

80-101: If keeping team.members temporarily, at least narrow the selection

Until the full include→select refactor lands, avoid fetching entire member objects. Narrow to the current user and just the fields needed for readOnly.

-        team: {
-          select: {
-            id: true,
-            slug: true,
-            name: true,
-            members: true,
-          },
-        },
+        team: {
+          select: {
+            id: true,
+            slug: true,
+            name: true,
+            members: {
+              where: { userId: ctx.user.id },
+              select: { userId: true, role: true, accepted: true },
+            },
+          },
+        },

Repeat for the similar blocks below.

Also applies to: 122-148, 176-202, 235-261

packages/features/eventtypes/components/tabs/workflows/EventWorkfowsTab.tsx (4)

145-153: Clarify tooltip when action is disabled due to permissions.

Tooltip currently shows “turn on/off” unless readOnly && children-managed. When disabled by PBAC (no canUpdate) but not readOnly, users still see “turn on/off” which is misleading.

-        <Tooltip
-          content={
-            t(
-              workflow.readOnly && props.isChildrenManagedEventType
-                ? "locked_by_team_admin"
-                : isActive
-                ? "turn_off"
-                : "turn_on"
-            ) as string
-          }>
+        <Tooltip
+          content={
+            t(
+              isLockedByAdmin
+                ? "locked_by_team_admin"
+                : canUpdate
+                ? (isActive ? "turn_off" : "turn_on")
+                : "permission_denied" // ensure this i18n key exists
+            ) as string
+          }>

---

116-121: Localize “Untitled (…)” per project i18n rule for TSX.

Replace the raw “Untitled” with t("untitled") to comply with the localization guideline.

-            {workflow.name
-              ? workflow.name
-              : `Untitled (${`${t(`${workflow.steps[0].action.toLowerCase()}_action`)}`
-                  .charAt(0)
-                  .toUpperCase()}${`${t(`${workflow.steps[0].action.toLowerCase()}_action`)}`.slice(1)})`}
+            {workflow.name
+              ? workflow.name
+              : `${t("untitled")} (${`${t(`${workflow.steps[0].action.toLowerCase()}_action`)}`
+                  .charAt(0)
+                  .toUpperCase()}${`${t(`${workflow.steps[0].action.toLowerCase()}_action`)}`.slice(1)})`}

---

93-99: Avoid adding empty recipients to the “to:” list.

sendTo.add(step.sendTo || "") can introduce an empty recipient entry. Minor polish to skip falsy values.

-      case WorkflowActions.EMAIL_ADDRESS:
-        sendTo.add(step.sendTo || "");
+      case WorkflowActions.EMAIL_ADDRESS:
+        if (step.sendTo) sendTo.add(step.sendTo);
         break;

---

1-1: File name typo (“EventWorkfowsTab”).

Consider renaming the file to EventWorkflowsTab.tsx for consistency with the component name and discoverability.

packages/platform/atoms/event-types/hooks/useTabsNavigations.tsx (3)

225-231: Localize “apps” label inside the info string.

The literal “apps” is embedded in a user-facing string in TSX. Prefer a single translatable string with count placeholders.

-      info: `${installedAppsNumber} apps, ${enabledAppsNumber} ${t("active")}`,
+      info: t("apps_summary", { count: installedAppsNumber, active: enabledAppsNumber }),

Follow-up: add apps_summary to locale files with pluralization.

---

146-154: Localize “Cal.ai” tab title.

Raw string should use t() in TSX to satisfy localization checks.

-        name: "Cal.ai",
+        name: t("cal_ai"),

---

74-86: Stabilize the useMemo dependency on id.

Calling formMethods.getValues("id") inside the dependency array re-evaluates each render. Capture it into a const and reference the const in both the call and dependencies.

-  const EventTypeTabs = useMemo(() => {
+  const eventTypeId = formMethods.getValues("id");
+  const EventTypeTabs = useMemo(() => {
     const navigation: VerticalTabItemProps[] = getNavigation({
       t,
       length,
       multipleDuration,
-      id: formMethods.getValues("id"),
+      id: eventTypeId,
@@
-  }, [
+  }, [
     t,
@@
-    formMethods.getValues("id"),
+    eventTypeId,
     watchSchedulingType,
@@
     canReadWorkflows,
   ]);

Also applies to: 172-173

packages/features/pbac/client/context/EventPermissionContext.tsx (1)

61-69: Helpful error message, consider adding a dev-friendly hint.

The thrown error is fine. Optionally append which component attempted to read the store (selector.toString()) for faster diagnosis during integration.

apps/web/app/(use-page-wrapper)/event-types/[type]/page.tsx (1)

76-79: Localize user-facing error messages.

Strings “Invalid Event Type id” and “This event type does not exist” are user-facing. Wrap via t() or throw a typed HttpError that maps to localized UI.

Also applies to: 85-86

packages/features/pbac/client/components/WorkflowTabPermissionGuard.tsx (1)

1-24: Simple and effective guard; make permission configurable for reuse.

Hard-coding "workflow.read" limits reuse. Consider accepting a permission prop defaulting to "workflow.read".

+import type { PermissionString } from "../../domain/types/permission-registry";
@@
-interface WorkflowTabPermissionGuardProps {
+interface WorkflowTabPermissionGuardProps {
   children: ReactNode;
   fallback?: ReactNode;
+  permission?: PermissionString;
 }
@@
-export const WorkflowTabPermissionGuard = ({
-  children,
-  fallback = null,
-}: WorkflowTabPermissionGuardProps) => {
-  const { hasPermission } = useWorkflowPermission("workflow.read");
+export const WorkflowTabPermissionGuard = ({
+  children,
+  fallback = null,
+  permission = "workflow.read",
+}: WorkflowTabPermissionGuardProps) => {
+  const { hasPermission } = useWorkflowPermission(permission);

packages/platform/atoms/event-types/wrappers/EventTypeWebWrapper.tsx (3)

111-116: Avoid recreating the permission store on every render

Because EventPermissionProvider internally creates a new store on each render, wrapping here means the store (and subscribers) will be recreated on any parent re-render. That can cause unnecessary re-renders and potential state loss if the store ever becomes stateful.

Refactor the provider to memoize the store once per mount.

Apply in packages/features/pbac/client/context/EventPermissionContext.tsx:

 export const EventPermissionProvider = ({ children, initialPermissions }: EventPermissionProviderProps) => {
-  const store = createEventPermissionStore(initialPermissions);
-
-  return <EventPermissionContext.Provider value={store}>{children}</EventPermissionContext.Provider>;
+  const storeRef = useRef<EventPermissionStore>();
+  if (!storeRef.current) {
+    storeRef.current = createEventPermissionStore(initialPermissions);
+  }
+  return <EventPermissionContext.Provider value={storeRef.current}>{children}</EventPermissionContext.Provider>;
 };

Also applies to: 120-124

---

151-153: Selector returns an object; prefer primitive to minimize re-renders

useWorkflowPermission currently returns an object { hasPermission, permissions }. Selecting an object in Zustand without an equality function re-renders on every store update. Select the boolean directly.

Change usage here:

-  const { hasPermission: canReadWorkflows } = useWorkflowPermission("workflow.read");
+  const canReadWorkflows = useWorkflowPermission("workflow.read");

And adjust the hook implementation accordingly (see comments in useEventPermission.ts below).

---

263-268: Refactor Workflows Tab gating for clearer UX and resilience

The Workflows tab is currently only rendered when both allActiveWorkflows (truthy) and canReadWorkflows are true, which can lead to:

• A flash of missing tab during data loading (when allActiveWorkflows is undefined).
• Navigation mismatches if the surrounding nav logic only checks permissions.
• Fragile handling when the workflows list is empty (an empty array is truthy, but gating on presence can still mask the tab during transient states).

Recommend instead gating solely on canReadWorkflows and passing a default empty array into the tab. The tab component itself should handle loading and “no workflows” states internally:

-    workflows:
-      allActiveWorkflows && canReadWorkflows ? (
-        <EventWorkflowsTab eventType={eventType} workflows={allActiveWorkflows} />
-      ) : (
-        <></>
-      ),
+    workflows: canReadWorkflows ? (
+      <EventWorkflowsTab
+        eventType={eventType}
+        workflows={allActiveWorkflows ?? []}
+      />
+    ) : (
+      <></>
+    ),

• Verified that the dynamic import path matches the actual filename (EventWorkfowsTab.tsx) and its default export is correctly named EventWorkflowsTab, so no import/runtime errors will occur.
• This change leaves permission checks in place while ensuring the tab remains present during loading or when no workflows exist.

packages/features/pbac/client/hooks/useEventPermission.ts (3)

6-11: Return a primitive from the selector to prevent needless re-renders

Selecting an object from Zustand without an equality comparator recreates a new object on any store change, causing component re-renders even when the boolean doesn’t change. Return the boolean directly.

-export const useEventTypePermission = (permission: PermissionString) => {
-  return useEventPermissionStore((state) => ({
-    hasPermission: state.hasEventTypePermission(permission),
-    permissions: state.permissions.eventTypes,
-  }));
-};
+export const useEventTypePermission = (permission: PermissionString) => {
+  return useEventPermissionStore((state) => state.hasEventTypePermission(permission));
+};

If consumers need the list of permissions as well, expose a separate hook (e.g., useEventTypePermissionList) to avoid coupling unrelated concerns.

---

20-25: Same here: return boolean for workflow permissions

Mirror the change for workflows to keep the API consistent and efficient.

-export const useWorkflowPermission = (permission: PermissionString) => {
-  return useEventPermissionStore((state) => ({
-    hasPermission: state.hasWorkflowPermission(permission),
-    permissions: state.permissions.workflows,
-  }));
-};
+export const useWorkflowPermission = (permission: PermissionString) => {
+  return useEventPermissionStore((state) => state.hasWorkflowPermission(permission));
+};

---

27-32: Optional: split multi-check from list exposure

useWorkflowPermissions returns both hasPermissions and the underlying list. If you want to minimize re-renders, consider returning only the boolean here, and add a dedicated accessor hook for the workflows list (e.g., useWorkflowPermissionList). Not blocking.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: supalarry
PR: calcom/cal.com#23217
File: apps/api/v2/src/ee/event-types/event-types_2024_06_14/services/output-event-types.service.ts:93-94
Timestamp: 2025-08-21T13:44:06.784Z
Learning: In apps/api/v2/src/ee/event-types/event-types_2024_06_14/event-types.repository.ts, repository functions that use explicit Prisma select clauses (like getEventTypeWithSeats) are used for specific purposes and don't need to include all EventType fields like bookingRequiresAuthentication. These methods don't feed into the general OutputEventTypesService_2024_06_14 flow.

Learnt from: SinghaAnirban005
PR: calcom/cal.com#23343
File: packages/features/insights/server/trpc-router.ts:1080-1101
Timestamp: 2025-08-26T08:08:23.383Z
Learning: In packages/features/insights/server/trpc-router.ts, when filtering personal event types (userId provided, no teamId, not isAll), the query correctly uses user.id (authenticated user) instead of the input userId parameter for security reasons. This prevents users from accessing other users' personal event types by passing arbitrary user IDs.