권한

소개

Permissions 탭은 특정 저장소에 대해 누가 어떤 폴더를 읽거나 쓸 수 있는지 정의합니다. 권한은 그룹 또는 사용자 를 대상으로 하며, 경로 패턴 에 적용되고, 수준（write / read / none）을 가집니다. 역할은 계정이 무엇을 할 수 있는지를, 권한은 어떤 파일에 대해서인지를 정합니다.

접근과 역할

이 탭은 슈퍼 관리자（모든 저장소）와 project_admin （자신이 관리하는 저장소）가 사용할 수 있습니다. 규칙은 항상 선택된 저장소에 연결됩니다.

세 가지 수준

수준	효과
write	대상 경로에서 읽기와 쓰기（체크아웃, 체크인）.
read	읽기 전용: 동기화는 가능하지만 수정은 불가.
none	접근 없음: 더 넓은 규칙이 허용하더라도 폴더를 명시적으로 숨깁니다.

접근 권한 부여

1. 저장소를 선택한 다음 Permissions 탭을 엽니다.
2. 선택기에서 대상 을 고릅니다: 그룹 또는 사용자（"Groups"와 "Users" 두 개의 하위 목록）. 하나의 규칙은 둘 중 하나만 대상으로 하며, 둘 다 대상으로 하지 않습니다.
3. 폴더 트리 에서 해당 폴더를 체크합니다（체크박스는 세 가지 상태: 전체 / 부분 / 없음）. 검색 필드로 트리를 필터링할 수 있습니다.
4. 나타나는 막대에서 수준（write / read / none）을 고르고 Apply 를 클릭합니다.

대상의 활성 규칙은 표（패턴, 수준, 우선순위）에 표시되며 하나씩 삭제할 수 있습니다.

사용자 이름으로 부여

"+ By username" 버튼을 사용하면 보이는 목록에 나타나지 않는 사람에게도 그 정확한 이름 을 입력하여 접근 권한을 부여할 수 있습니다. 이는 아직 어떤 권한도 갖지 않은 playtester 처럼 평소 범위 밖의 계정에 접근 권한을 부여하는 방법입니다.

이름은 정확히 일치해야 합니다（접두사 불가）. 이 필드는 식별자와 이름만 반환하며, 역할은 결코 반환하지 않습니다. 기존 계정을 탐색하는 데 사용되지 않도록 하기 위함입니다.

패턴과 우선순위

체크한 폴더 Foo/Bar 는 패턴 Foo/Bar/** 가 됩니다（해당 폴더와 임의의 깊이에 포함된 모든 것）. 저장소 루트는 /** 가 됩니다.

각 규칙에는 폴더의 깊이와 같은 우선순위 가 자동으로 부여됩니다（세그먼트 수, 루트 = 0）. 따라서 더 구체적（더 깊은）인 규칙이 더 일반적인 규칙보다 우선합니다. 예: Content/** 에 write, Content/Secret/** 에 none 을 지정하면, Content/ 전체에서 쓰기가 가능하지만 Secret/ 만 제외됩니다.

기본 해석

명시적 규칙이 경로를 다루지 않을 때, 실효 접근은 다음 모델을 따릅니다:

• 기본적으로, 일치하는 규칙이 없으면 접근은 read（읽기）입니다.
• admin 과 lead 는 어디서나 write（역할 우회）를 가집니다.
• project_admin 은 자신이 관리하는 저장소에서 write 를 가지며, 그 외에는 특별한 권한이 없습니다.
• 그 밖에는 가장 구체적인 규칙이 적용됩니다. 해당이 없으면 기본 읽기입니다.

다시 말해: 누군가에게 폴더 읽기를 금지 하려면 아무것도 부여하지 않는 것만으로는 충분하지 않고 （기본이 read이므로）, 명시적인 none 규칙이 필요합니다.

권한 테스트

Test Permission 패널은 「이 사용자가 이 경로에 대해 어떤 실효 접근을 갖는가?」에 답합니다. 사용자를 선택하고 경로（예: /Content/Maps/Level01.umap）를 입력한 뒤 테스트를 실행합니다. 결과에는 실효 수준과 함께 결정을 내린 소스 와 패턴 이 표시되어, 접근이 허용되거나 거부되는 이유를 이해할 수 있습니다.

볼 권한이 없는 사용자에 대해서는, 테스트가 존재하지 않는 계정과 동일한 「찾을 수 없음」을 반환하여 계정의 존재를 드러내지 않습니다.

흔한 함정

「아무것도 부여하지 않았는데 읽을 수 있다」

이는 read 기본값 때문입니다. 폴더를 닫으려면 해당 폴더에 명시적인 none 규칙을 설정하세요.

두 규칙이 서로 모순된다

가장 구체적인 것（가장 깊은 깊이）이 이깁니다. 어느 것이 결정하는지는 테스트 로 확인하세요.

none 규칙이 있는데도 lead가 쓰기 상태로 남는다

admin 과 lead 역할은 경로 규칙을 우회합니다（어디서나 write）. none 규칙으로도 제한되지 않습니다. project_admin 이 자신의 저장소에 대해 갖는 경우도 마찬가지입니다.

그룹을 통한 접근과 직접 접근

접근은 계정 자체에서 오거나, 소속된 그룹 에서 올 수 있습니다. 규칙을 제거해도 아무것도 바뀌지 않으면, 다른 소스를 찾으세요（어느 것이 적용되는지는 테스트가 알려줍니다）.