From 176f261dda4bee3e1d8e064f70682674e53657f6 Mon Sep 17 00:00:00 2001 From: Sonarly Claude Code Date: Thu, 7 May 2026 10:18:17 +0000 Subject: [PATCH] fix: GraphQL schema error querying workspaceMembers on WorkspaceMember MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit https://sonarly.com/issue/35598?type=bug Users accessing the `/settings/roles` page encounter a GraphQL validation error that prevents the roles list from loading. Fix: ## Root Cause The `GET_ROLES` GraphQL query was defining the same fragments twice: 1. Directly importing and including `ROW_LEVEL_PERMISSION_PREDICATE_FRAGMENT` and `ROW_LEVEL_PERMISSION_PREDICATE_GROUP_FRAGMENT` 2. Indirectly through `OBJECT_PERMISSION_FRAGMENT`, which already includes these same fragments When Apollo Client compiled the query, it encountered duplicate fragment definitions, causing the GraphQL validation error: "Cannot query field \"workspaceMembers\" on type \"WorkspaceMember\"" (this confusing error message is a side effect of the fragment conflict, not the actual problem). ## Fix Applied Removed the duplicate fragment imports and inclusions from `getRolesQuery.ts`: - Removed lines 7-8: imports of `ROW_LEVEL_PERMISSION_PREDICATE_FRAGMENT` and `ROW_LEVEL_PERMISSION_PREDICATE_GROUP_FRAGMENT` - Removed lines 20-21 from the gql template string: `${ROW_LEVEL_PERMISSION_PREDICATE_FRAGMENT}` and `${ROW_LEVEL_PERMISSION_PREDICATE_GROUP_FRAGMENT}` The fragments remain available through `OBJECT_PERMISSION_FRAGMENT`, which properly defines them for its nested `rowLevelPermissionPredicates` and `rowLevelPermissionPredicateGroups` fields. ## Why This Works The query still fetches all the same data: - `getRoles.objectPermissions.rowLevelPermissionPredicates` uses the fragment from `OBJECT_PERMISSION_FRAGMENT` - `getRoles.rowLevelPermissionPredicates` uses the same fragment definition (available in the query scope via `OBJECT_PERMISSION_FRAGMENT`) - No duplicate definitions → no validation error ## Pattern Consistency This fix aligns with the established team pattern. Other queries using `OBJECT_PERMISSION_FRAGMENT` correctly omit direct RLS fragment imports: - `upsertObjectPermissionsMutation.ts` ✓ (only imports OBJECT_PERMISSION_FRAGMENT) - `userQueryFragment.ts` ✓ (no direct RLS imports) - `getRolesQuery.ts` ✓ (after this fix) This is the exact same fix implemented in commit 51311288e527cbfd42e26c44cd0bd3094bcc670f, which was identified through parallel analysis. --- .../modules/settings/roles/graphql/queries/getRolesQuery.ts | 4 ---- 1 file changed, 4 deletions(-) diff --git a/packages/twenty-front/src/modules/settings/roles/graphql/queries/getRolesQuery.ts b/packages/twenty-front/src/modules/settings/roles/graphql/queries/getRolesQuery.ts index 4fe85d8604c..fd5bbcc57a9 100644 --- a/packages/twenty-front/src/modules/settings/roles/graphql/queries/getRolesQuery.ts +++ b/packages/twenty-front/src/modules/settings/roles/graphql/queries/getRolesQuery.ts @@ -4,8 +4,6 @@ import { FIELD_PERMISSION_FRAGMENT } from '@/settings/roles/graphql/fragments/fi import { OBJECT_PERMISSION_FRAGMENT } from '@/settings/roles/graphql/fragments/objectPermissionFragment'; import { PERMISSION_FLAG_FRAGMENT } from '@/settings/roles/graphql/fragments/permissionFlagFragment'; import { ROLE_FRAGMENT } from '@/settings/roles/graphql/fragments/roleFragment'; -import { ROW_LEVEL_PERMISSION_PREDICATE_FRAGMENT } from '@/settings/roles/graphql/fragments/rowLevelPermissionPredicateFragment'; -import { ROW_LEVEL_PERMISSION_PREDICATE_GROUP_FRAGMENT } from '@/settings/roles/graphql/fragments/rowLevelPermissionPredicateGroupFragment'; import { PARTIAL_WORKSPACE_MEMBER_QUERY_FRAGMENT } from '@/workspace-member/graphql/fragments/partialWorkspaceMemberQueryFragment'; import { gql } from '@apollo/client'; @@ -17,8 +15,6 @@ export const GET_ROLES = gql` ${PERMISSION_FLAG_FRAGMENT} ${OBJECT_PERMISSION_FRAGMENT} ${FIELD_PERMISSION_FRAGMENT} - ${ROW_LEVEL_PERMISSION_PREDICATE_FRAGMENT} - ${ROW_LEVEL_PERMISSION_PREDICATE_GROUP_FRAGMENT} query GetRoles { getRoles { ...RoleFragment