Félix Malfait
b7f5445926
## Problem The ESLint rule `graphql-resolvers-should-be-guarded` introduced in #15392 was failing on main because the guard `SettingsPermissionsGuard` had inconsistent naming. ## Root Cause The guard was named `SettingsPermissionsGuard` (with an 's') which was inconsistent with other permission guards: - ✅ `CustomPermissionGuard` - ✅ `NoPermissionGuard` - ✅ `ImpersonatePermissionGuard` - ❌ `SettingsPermissionsGuard` (inconsistent!) The ESLint rule checks if guard names end with `PermissionGuard`, but `SettingsPermissionsGuard` ends with `sGuard`, so it wasn't recognized as a permission guard. ## Solution Renamed the guard to be consistent with the naming convention: 1. ✅ Renamed file: `settings-permissions.guard.ts` → `settings-permission.guard.ts` 2. ✅ Renamed export: `SettingsPermissionsGuard` → `SettingsPermissionGuard` 3. ✅ Renamed internal class: `SettingsPermissionsMixin` → `SettingsPermissionMixin` 4. ✅ Updated all 122 references across 44 files in the codebase 5. ✅ Renamed test file: `settings-permissions.guard.spec.ts` → `settings-permission.guard.spec.ts` ## Testing - ✅ `npx nx run twenty-server:lint` passes - ✅ `npx nx run twenty-server:typecheck` passes - ✅ No references to the old name remain in the codebase - ✅ All previously failing resolver files now pass ESLint validation ## Related Fixes issues introduced in #15392
24 lines
859 B
TypeScript
24 lines
859 B
TypeScript
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 SettingsPermissionGuard
|
|
//
|
|
// 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;
|
|
}
|
|
}
|