パーミッション

はじめに

Permissions タブは、指定したリポジトリについて、誰がどのフォルダーを読み書きできるかを定義します。 パーミッションは グループまたはユーザー を対象とし、パスのパターン に適用され、 レベル（write / read / none）を持ちます。ロールはアカウントに何ができるかを、パーミッションは どのファイルに対してかを定めます。

アクセスとロール

このタブは スーパー管理者（すべてのリポジトリ）と project_admin （管理しているリポジトリ）が利用できます。ルールは常に選択中のリポジトリに紐づきます。

3つのレベル

レベル	効果
write	対象パスでの読み取りと書き込み（チェックアウト、チェックイン）。
read	読み取り専用: 同期はできますが変更はできません。
none	アクセスなし: より広いルールが許可する場合でも、フォルダーを明示的に隠します。

アクセスの付与

1. リポジトリを選択し、次に Permissions タブを開きます。
2. セレクターで 対象 を選びます: グループ または ユーザー（「Groups」と「Users」の 2つのサブリスト）。1つのルールはどちらか一方のみを対象とし、両方は対象にしません。
3. フォルダーツリー で対象のフォルダーにチェックを入れます（チェックボックスは3状態: すべて / 一部 / なし）。検索フィールドでツリーを絞り込めます。
4. 表示されるバーでレベル（write / read / none）を選び、 Apply をクリックします。

対象の有効なルールは表（パターン、レベル、優先度）に表示され、1つずつ削除できます。

ユーザー名で付与

"+ 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 ルールを そのフォルダーに設定してください。

2つのルールが矛盾する

最も具体的なもの（深さが最大）が勝ちます。どちらが決定するかは テスト で確認してください。

none ルールがあるのに lead が書き込みのまま

admin と lead のロールはパスのルールをバイパスします（どこでも write）。none ルールでも制限されません。project_admin が自身のリポジトリに対して持つ場合も同様です。

グループ経由のアクセスと直接のアクセス

アクセスはアカウント自身から来る場合と、所属する グループ から来る場合があります。 ルールを削除しても何も変わらない場合は、もう一方のソースを探してください（どちらが適用されるかはテストが示します）。