커스텀 역할 개발 가이드라인

GitLab Ultimate에서 커스텀 역할을 생성하고, 권한(ability)을 추가·구성·테스트하는 개발 가이드라인을 설명합니다.

Ultimate 고객은 커스텀 역할을 생성하고, 특정 권한(ability)을 지정하여 해당 역할을 정의할 수 있습니다. 예를 들어, 사용자는 read code 와 admin merge requests 권한을 가지지만 admin issues 와 같은 권한은 없는 "Engineer" 역할을 만들 수 있습니다. 이 맥락에서 "permission"과 "ability"라는 용어는 종종 혼용됩니다. "Ability"는 사용자가 수행할 수 있는 작업입니다. 이는 Declarative Policy abilities 에 매핑되며, ee/app/policies/* 의 Policy 클래스에 존재합니다. "Permission"은 사용자 대상 문서 에서 ability를 지칭하는 방식입니다. 권한 문서는 수동으로 생성되므로, 문서에 나열된 권한과 Policy 클래스에 정의된 ability가 반드시 1:1로 매핑되지는 않습니다. 커스텀 역할 vs 기본 역할 # GitLab 15.9 이하에서 GitLab은 권한 시스템으로 기본 역할 만 사용했습니다. 이 시스템에는 특정 권한(ability)에 정적으로 할당된 몇 가지 사전 정의된 역할이 있습니다. 이러한 기본 역할은 고객이 사용자 정의할 수 없습니다. 커스텀 역할을 사용하면 고객이 특정 사용자 그룹에 어떤 권한(ability)을 부여할지 결정할 수 있습니다. 예를 들어: 기본 역할 시스템에서 취약점 읽기는 Developer 권한으로 제한됩니다. 커스텀 역할 시스템에서 고객은 이 권한(ability)을 임의의 기본 역할을 기반으로 하는 새 커스텀 역할에 할당할 수 있습니다. 기본 역할과 마찬가지로, 커스텀 역할도 그룹 계층 내에서 상속 됩니다. 사용자가 그룹에 대한 커스텀 역할을 가지고 있으면, 해당 사용자는 그룹 내의 모든 프로젝트나 하위 그룹에 대해서도 커스텀 역할을 가집니다. 기술 개요 # 개별 커스텀 역할은 member_roles 테이블( MemberRole 모델)에 저장됩니다. member_roles 레코드는 namespace_id 외래 키를 통해 최상위 그룹(하위 그룹 아님)과 연결됩니다. 그룹 또는 프로젝트 멤버십( members 레코드)은 member_role_id 외래 키를 통해 커스텀 역할과 연결됩니다. 그룹 또는 프로젝트 멤버십은 해당 그룹 또는 프로젝트의 루트 수준 그룹에 정의된 임의의 커스텀 역할과 연결될 수 있습니다. member_roles 테이블에는 개별 권한과 base_access_level 값이 포함됩니다. base_access_level 은 유효한 액세스 수준이어야 합니다. 가능한 값: 0 (액세스 없음), 5 (최소 액세스), 10 (Guest), 15 (Planner), 20 (Reporter), 25 (Security Manager), 30 (Developer), 40 (Maintainer), 50 (Owner), 60 (Admin). base_access_level 은 커스텀 역할에 포함되는 권한(ability)을 결정합니다. 예를 들어, base_access_level 이 10