Enhance role-check system with stricter checks (#15392)

## Overview This PR strengthens our permission system by introducing more granular role-based access control across the platform. ## Changes ### New Permissions Added - **Applications** - Control who can install and manage applications - **Layouts** - Control who can customize page layouts and UI structure - **AI** - Control access to AI features and agents - **Upload File** - Separate permission for file uploads - **Download File** - Separate permission for file downloads (frontend visibility) ### Security Enhancements - Implemented whitelist-based validation for workspace field updates - Added explicit permission guards to core entity resolvers - Enhanced ESLint rule to enforce permission checks on all mutations - Created `CustomPermissionGuard` and `NoPermissionGuard` for better code documentation ### Affected Components - Core entity resolvers: webhooks, files, domains, applications, layouts, postgres credentials - Workspace update mutations now use whitelist validation - Settings UI updated with new permission controls ### Developer Experience - ESLint now catches missing permission guards during development - Explicit guard markers make permission requirements clear in code review - Comprehensive test coverage for new permission logic ## Testing - ✅ All TypeScript type checks pass - ✅ ESLint validation passes - ✅ New permission guards properly enforced - ✅ Frontend UI displays new permissions correctly ## Migration Notes Existing workspaces will need to assign the new permissions to roles as needed. By default, all new permissions are set to `false` for non-admin roles.
2025-11-07 15:37:17 +01:00
parent 44d6ec2594
commit cff17db6cb
306 changed files with 13863 additions and 976 deletions
@@ -0,0 +1,32 @@
+import { type ExecutionContext } from '@nestjs/common';
+
+import { CustomPermissionGuard } from 'src/engine/guards/custom-permission.guard';
+
+describe('CustomPermissionGuard', () => {
+  let guard: CustomPermissionGuard;
+  let mockExecutionContext: ExecutionContext;
+
+  beforeEach(() => {
+    guard = new CustomPermissionGuard();
+    mockExecutionContext = {} as ExecutionContext;
+  });
+
+  describe('canActivate', () => {
+    it('should always return true', () => {
+      const result = guard.canActivate(mockExecutionContext);
+
+      expect(result).toBe(true);
+    });
+
+    it('should return true even with different contexts', () => {
+      const differentContext = {
+        switchToHttp: jest.fn(),
+        getHandler: jest.fn(),
+      } as unknown as ExecutionContext;
+
+      const result = guard.canActivate(differentContext);
+
+      expect(result).toBe(true);
+    });
+  });
+});
@@ -0,0 +1,32 @@
+import { type ExecutionContext } from '@nestjs/common';
+
+import { NoPermissionGuard } from 'src/engine/guards/no-permission.guard';
+
+describe('NoPermissionGuard', () => {
+  let guard: NoPermissionGuard;
+  let mockExecutionContext: ExecutionContext;
+
+  beforeEach(() => {
+    guard = new NoPermissionGuard();
+    mockExecutionContext = {} as ExecutionContext;
+  });
+
+  describe('canActivate', () => {
+    it('should always return true', () => {
+      const result = guard.canActivate(mockExecutionContext);
+
+      expect(result).toBe(true);
+    });
+
+    it('should return true even with different contexts', () => {
+      const differentContext = {
+        switchToHttp: jest.fn(),
+        getHandler: jest.fn(),
+      } as unknown as ExecutionContext;
+
+      const result = guard.canActivate(differentContext);
+
+      expect(result).toBe(true);
+    });
+  });
+});
@@ -0,0 +1,89 @@
+import { type ExecutionContext } from '@nestjs/common';
+import { GqlExecutionContext } from '@nestjs/graphql';
+
+import { WorkspaceActivationStatus } from 'twenty-shared/workspace';
+
+import { SettingsPermissionsGuard } from 'src/engine/guards/settings-permissions.guard';
+import { PermissionFlagType } from 'src/engine/metadata-modules/permissions/constants/permission-flag-type.constants';
+import { PermissionsException } from 'src/engine/metadata-modules/permissions/permissions.exception';
+import { type PermissionsService } from 'src/engine/metadata-modules/permissions/permissions.service';
+
+describe('SettingsPermissionsGuard', () => {
+  let guard: any;
+  let mockPermissionsService: jest.Mocked<PermissionsService>;
+  let mockExecutionContext: ExecutionContext;
+  let mockGqlContext: any;
+
+  beforeEach(() => {
+    mockPermissionsService = {
+      userHasWorkspaceSettingPermission: jest.fn(),
+    } as any;
+
+    mockGqlContext = {
+      req: {
+        workspace: {
+          id: 'workspace-id',
+          activationStatus: WorkspaceActivationStatus.ACTIVE,
+        },
+        userWorkspaceId: 'user-workspace-id',
+        apiKey: null,
+      },
+    };
+
+    mockExecutionContext = {} as ExecutionContext;
+
+    jest
+      .spyOn(GqlExecutionContext, 'create')
+      .mockReturnValue({ getContext: () => mockGqlContext } as any);
+
+    const GuardClass = SettingsPermissionsGuard(PermissionFlagType.WORKSPACE);
+
+    guard = new GuardClass(mockPermissionsService);
+  });
+
+  afterEach(() => {
+    jest.restoreAllMocks();
+  });
+
+  describe('canActivate', () => {
+    it('should bypass permission check when workspace is being created', async () => {
+      mockGqlContext.req.workspace.activationStatus =
+        WorkspaceActivationStatus.PENDING_CREATION;
+
+      const result = await guard.canActivate(mockExecutionContext);
+
+      expect(result).toBe(true);
+      expect(
+        mockPermissionsService.userHasWorkspaceSettingPermission,
+      ).not.toHaveBeenCalled();
+    });
+
+    it('should return true when user has required permission', async () => {
+      mockPermissionsService.userHasWorkspaceSettingPermission.mockResolvedValue(
+        true,
+      );
+
+      const result = await guard.canActivate(mockExecutionContext);
+
+      expect(result).toBe(true);
+      expect(
+        mockPermissionsService.userHasWorkspaceSettingPermission,
+      ).toHaveBeenCalledWith({
+        userWorkspaceId: 'user-workspace-id',
+        setting: PermissionFlagType.WORKSPACE,
+        workspaceId: 'workspace-id',
+        apiKeyId: undefined,
+      });
+    });
+
+    it('should throw PermissionsException when user lacks permission', async () => {
+      mockPermissionsService.userHasWorkspaceSettingPermission.mockResolvedValue(
+        false,
+      );
+
+      await expect(guard.canActivate(mockExecutionContext)).rejects.toThrow(
+        PermissionsException,
+      );
+    });
+  });
+});
@@ -0,0 +1,23 @@
+import {
+  type CanActivate,
+  type ExecutionContext,
+  Injectable,
+} from '@nestjs/common';
+
+// Guard that explicitly marks an endpoint as having custom permission logic
+// This guard always returns true and serves as documentation that the endpoint
+// has custom permission checks implemented within the resolver method itself
+//
+// Use this when you need custom permission validation that cannot be expressed
+// with standard SettingsPermissionsGuard
+//
+// Examples of when to use CustomPermissionGuard:
+// - Self-only operations (users can only modify their own data)
+// - Complex permission logic (multiple conditions)
+// - Dynamic permission requirements (depends on object type, record ownership, etc.)
+@Injectable()
+export class CustomPermissionGuard implements CanActivate {
+  canActivate(_context: ExecutionContext): boolean {
+    return true;
+  }
+}
@@ -0,0 +1,25 @@
+import {
+  type CanActivate,
+  type ExecutionContext,
+  Injectable,
+} from '@nestjs/common';
+
+// Guard that explicitly marks an endpoint as NOT requiring permission checks
+// This guard always returns true and serves as explicit documentation that
+// the endpoint intentionally bypasses standard permission validation
+//
+// Use this ONLY for special cases where permission checks don't apply:
+// - Workspace initialization/onboarding flows
+// - Public or semi-public endpoints
+// - Self-service operations that don't require elevated permissions
+//
+// Examples: activateWorkspace (onboarding), user profile updates
+//
+// WARNING: Use sparingly! Most mutations should use SettingsPermissionsGuard
+// If you're unsure, use CustomPermissionGuard and implement checks in the method
+@Injectable()
+export class NoPermissionGuard implements CanActivate {
+  canActivate(_context: ExecutionContext): boolean {
+    return true;
+  }
+}