관리자가 반복 사용할 권한 묶음을 제공합니다. 프리셋 공개만으로 사용자에게 접근 권한이 생기지는 않습니다.

책임 단위 프리셋 공개

App contribution 경로에서 SDK RolePresetContribution::rolePresets()를 구현합니다. 안정적인 키와 revision, 권장 할당 범위, 대상 사용자, 위험도, 기존 권한 키를 RolePreset에 담습니다. 아래 Assets 사례는 테넌트 정의 조회와 Legal Entity 업무 운영을 분리합니다.

한 책임을 표현하는 크기로 권한을 묶고 각 권한의 할당 범위와 대상 집단을 맞추세요. 메뉴를 보이게 할 목적으로 광범위한 권한을 끼워 넣지 않습니다. 새 contribution 클래스는 discovery를 갱신해야 반영됩니다.

결과 확인

역할 구성에서 프리셋을 선택할 수 있어야 합니다. 설치나 발견 단계에서는 권한이 부여되지 않으며 관리자가 역할을 구성하고 할당해야 합니다. 최종 API 권한은 App 테스트하기로 확인하세요.

구성과 유지 관리

Role Preset은 직무에 맞는 권한 조합을 제안합니다. 접근 관리자가 Role을 만들거나 복제할 때 선택하며, 만들어진 Role은 테넌트가 관리합니다.

App Catalog의 초기 권한 dialog도 preset을 채택하는 화면입니다. Pending App이 소유한 preset 중 deprecated되지 않은 비기술 항목이면서 tenant 또는 현재 Legal Entity scope를 권장하는 항목만 표시합니다. Operating Unit preset은 일반 Access 흐름에서 계속 다룹니다.

packages/assets의 실제 모양입니다.

코드 예시

PHP

final class AssetManagementRolePresets implements \Nexia\Permission\Contracts\RolePresetContribution
{
    public static function rolePresets(): array
    {
        return [\Nexia\Permission\RolePreset::fromArray([
            'key' => 'assets.tenant_definition_reader',
            'app_key' => 'assets',
            'version' => 1,
            'name' => 'Asset Definition Reader',
            'description' => 'Reads tenant-wide asset types, classifications, and active policy definitions used by LegalEntity operations.',
            'recommended_scope' => \Nexia\Permission\AssignmentScope::Tenant->value,
            'type' => \Nexia\Permission\PresetType::Capability->value,
            'audience' => \Nexia\Permission\PermissionDefinition::AUDIENCE_INTERNAL,
            'risk' => \Nexia\Permission\PermissionDefinition::RISK_STANDARD,
            'permissions' => [
                'assets.asset_type.read',
                'assets.asset_category.read',
                'assets.asset_policy.read',
            ],
            'deprecated' => false,
            'replacement_key' => null,
        ])];
    }
}123456789101112131415161718192021222324

packages/assets/src/Contribution/AssetManagementRolePresets.php의 첫 프리셋을 펼친 예시입니다. SDK RolePreset을 반환하며 실제 구현은 공통 필드를 helper에서 구성합니다.

필드 레퍼런스

키	타입	동작
`key`	string	안정적, App 접두 preset 식별자
`app_key`	string	소유 App
`version`	int	권장 집합이 의미 있게 바뀔 때 올림
`name`	string	사람이 보는 preset 이름
`description`	string	직무가 하는 일. Role 구성 중에 표시됨
`recommended_scope`	`AssignmentScope` 값	`tenant`, `legal_entity`, `operating_unit`
`audience`	string	직원용 preset은 `PermissionDefinition::AUDIENCE_INTERNAL`
`risk`	string	`standard`, `elevated`, `privileged`
`permissions`	string 목록	모두 이 App이 소유한 권한 키
`deprecated`	bool	기존 Role은 유지하고 새 선택에서 숨김
`replacement_key`	string, null	폐기됐을 때 대신 갈 곳
`type`	`PresetType` 값	`job`, `capability`, `technical`

risk는 정직하게 매기세요. preset이 검토가 필요한지 관리자가 판단하는 신호입니다. packages/assets에서 자산 정의를 읽는 preset은 RISK_STANDARD이고 같은 정의를 유지 관리하는 preset은 RISK_PRIVILEGED입니다.

type은 묶음이 무엇을 나타내는지로 고릅니다.

타입	의미
`job`	사람이 맡는 하나의 온전한 역할
`capability`	다른 것과 조합되는 일관된 능력 하나
`technical`	사람의 직무가 아니라 통합·서비스 접근

경계 규칙

Preset 자체는 절대 부여하지 않습니다. App이 preset을 배포하거나 catalog가 발견했다는 사실만으로 권한이 생기지 않습니다. 명시적인 채택 workflow는 preset 자체를 granting하게 만들지 않으면서 preset을 materialize하고 배정할 수 있습니다. App Catalog의 초기 권한 dialog가 그 workflow입니다. 권한 있는 관리자가 deprecated되지 않은 비기술 preset과 사용자를 고르면 Core가 선택한 각 scope에 테넌트 소유 Role과 감사 가능한 Grant를 만듭니다. 행위자가 self-approve할 수 없는 protected preset은 Grant 없이 materialize되며 protected-access 승인 흐름을 계속 거칩니다.

Preset은 Permission Catalog가 아닙니다. 무엇이 부여 가능한지는 카탈로그가 정본이고 preset은 선별된 부분집합입니다. 어떤 카탈로그 contributor도 공개하지 않는 권한을 절대 나열하지 마세요. 부여할 수 없고 preset이 조용히 부족해집니다.

Preset은 Role을 소급 갱신하지 않습니다. version을 올리면 새 선택이 받는 것이 바뀝니다. 이전 버전으로 이미 구성된 Role은 자기 권한을 유지합니다. 권한이 위험해졌다면 preset이 아니라 권한 자체를 nexia-access:retire-permission으로 폐기하세요.

자기 권한만. preset은 그 App이 소유한 키를 나열합니다. 다른 App의 권한을 묶는 것은 App 경계를 넘고 해석되지 않습니다.

작게 유지하기

권한 예순 개짜리 preset은 카탈로그의 사본이고 관리자에게 아무것도 알려주지 않습니다. 직무 하나를 겨냥하고, 하나의 방대한 job preset보다 조합되는 작은 capability preset 여럿을 선호하세요.

packages/assets가 테넌트 정의를 읽는 것과 유지 관리하는 것을 분리해서, 읽기 묶음은 넓게 부여하고 유지 관리 묶음은 좁게 부여할 수 있습니다. 그 분리가 가치입니다.