パーミッション

はじめに

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

アクセスとロール

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

タブの3つのパネル

Permissions タブは、管理パネルの PROJECT 行にあります。ここで行うことはすべて、 行の先頭にあるセレクターで表示されているリポジトリにのみ適用されます。すぐ上の SERVER 行は逆に サーバー全体に関わり、アカウントとグループはそこにあります。

このタブは上から下へ 3つの異なるパネル を積み重ねています。これらは3つの異なる問いに答えるもので、 最初の2つをフォルダーツリーと混同することが、このページで最も多い問い合わせの原因です。

パネル	答える問い	アクセスできる人
Project Admins	このプロジェクトを誰が管理するか？	スーパー管理者のみ
Build Access	このプロジェクトのビルドを誰がダウンロードできるか？	スーパー管理者と project_admin
パーミッションツリー	誰がどのフォルダーを読み書きできるか？	スーパー管理者と project_admin

このページの残りでは、まず主パネルであるパーミッションツリーを説明し、次に残りの2つを説明します。

3つのレベル

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

アクセスの付与

1. 正しいプロジェクトで Permissions タブを開く

PROJECT 行、行の先頭にあるリポジトリセレクター: 何よりもまず表示されているプロジェクトを確認して ください。ルールはそのプロジェクトだけに紐づきます。

2. 対象を選ぶ

セレクターでグループ または ユーザーを選びます。リストは Groups と Users の2つのサブリストに分かれています。1つのルールはどちらか一方のみを対象とし、両方は 対象にしません。対象が選ばれていない間、Apply ボタンは無効のままです。

3. フォルダーにチェックを入れる

フォルダーツリー で対象のフォルダーにチェックを入れます。チェックボックスは3状態 （すべて、一部、なし）で、Filter folders... フィールドはプロジェクトが大きいときにツリーを 絞り込みます。

4. レベルを選んで適用する

フォルダーにチェックを入れるとすぐにバーが表示されます。選択したフォルダーの数を示し、3つのレベル （write、read、none）を提示します。1つを選んで Apply を クリックします。すると対象のルールが下の Active rules テーブル（Path Pattern、 Permission、Priority）に表示され、1つずつ削除できます。

ユーザー名で付与

"+ By username" ボタンを使うと、表示されているリストに現れないユーザーにも、その 正確な名前 を入力してアクセスを付与できます。これは、まだ何のパーミッションも持たない playtester のように、通常の範囲外のアカウントにアクセスを付与する手段です。

名前は 完全に一致 する必要があります（前方一致は不可）。このフィールドは識別子と名前のみを返し、 ロールは決して返しません。既存アカウントの探索に使われないためです。

パターンと優先度

ルールは特定のファイルではなく パスのパターン、いわゆる glob を対象とします。 これは省略記法で、* は名前の中の任意の文字の並びを、** は任意の深さの任意のフォルダーの 並びを表します。したがって Content/Maps/** は Content/Maps の下にあるすべて（サブ フォルダーを含む）を指します。手で書く必要はありません。ツリーでフォルダーにチェックを入れると、対応する glob が 生成されます。

チェックしたフォルダー Foo/Bar はパターン Foo/Bar/** になります（そのフォルダーと、 任意の深さに含まれるすべて）。リポジトリのルートは /** になります。

各ルールには、フォルダーの 深さに等しい優先度 が自動的に付与されます（セグメント数、ルート = 0）。 したがって、より 具体的（より深い）なルールが、より一般的なルールに優先します。 例: Content/** に write、Content/Secret/** に none を設定すると、 Content/ 全体で書き込み可能ですが、Secret/ は除外されます。

既定の解決

明示的なルールがパスをカバーしない場合、実効的なアクセスは次のモデルに従います:

• 既定では、一致するルールがないとき、アクセスは read（読み取り）です。
• admin と lead は どこでも write（ロールのバイパス）です。
• project_admin は 管理するリポジトリで write を持ち、それ以外では特別な扱いは ありません。
• それ以外では、最も具体的なルールが適用されます。該当がなければ既定の読み取りです。

言い換えると: すでにリポジトリにアクセスできる 人にフォルダーの読み取りを 禁止 するには、何も付与しないだけでは不十分で（既定が read のため）、明示的な none ルールが必要です。

実務上の帰結で、無駄な作業を省けます: ルールのまったくない新規プロジェクトは、すでに全員に対して閉じて います。ただし admin と lead のロール、そしてそのプロジェクト自身の project_admin は除きます。したがってプロジェクトを「閉じる」ために至る所に none ルールを置く必要はありません。開き たいものだけを付与すれば十分です。none ルールは、すでに付与したアクセスの 内側 を区切るために 使います。たとえば Content/ を持つチームから Content/Secret/ を隠すためです。

プロジェクト管理者の指名

タブ上部の Project Admins パネルは、選択中のリポジトリを誰が管理するかを指定します。これは スーパー管理者専用 です。権限を与えることは、それを行使することより一段上だからです。

手順は次の順序で2段階です:

1. Users タブでロールを与える

SERVER 行、Users タブ: その人に project_admin ロールを与えます。 このロールが設定されるまで、その人はこのパネルの一覧に現れず、パネルにもこう表示されます: 「No one to add. Give someone the Project Admin role on the Users tab first」。

2. その人をリポジトリに結び付ける

ここに戻り、PROJECT 行のセレクターで表示されているリポジトリを確認し、Project Admins パネルで Add をクリックし、その人を選んで Grant をクリックします。その人はただちにパネルの 一覧に現れます。

結び付けを外す

行末の赤い×印（Revoke）は、そのリポジトリを対象範囲から外します。結び付けのないロールは 何も 与えません: どのリポジトリも管理しなくなった project_admin は、Permissions、Rules、Webhooks、 Files、そしてユーザー管理へのアクセスを失います。したがって最後のリポジトリを外すと、権限全体が外れます。

ビルドへのアクセス

Build Access パネルは、このプロジェクトの 公開済みビルド を、クライアントの Games ページから誰が見てダウンロードできるかを決めます。スーパー管理者 と、自分のリポジトリに対する project_admin に開かれています。

1. 追加フォームを開く

Build Access パネルで Add をクリックします。入力行が現れ、まず対象の指定方法の 選択から始まります。

2. 対象を指定する

• User: 一覧にあるアカウント、つまりすでにプロジェクトで作業している人。
• Group: グループ 全体。学生の一団や繰り返し使うテストチームに 便利です。
• By username: アカウントの正確な名前を入力する Exact username フィールド。 playtester にとっての通常の方法です。どの一覧にも現れないためです。名前は前方一致ではなく、正確に一致する必要が あります。

3. 付与する、または取り消す

付与するには Grant をクリックします。既存の行では、Revoke が確認をともなって アクセスを取り消します。

サーバーが適用するルール、順に:

誰が	ビルドへのアクセス
admin	すべてのリポジトリ。
project_admin	管理するリポジトリ。
その他すべてのロール	download_builds の権限を持つ必要があり（viewer を 除くすべてのロールが持ちます）、かつ リポジトリにアクセスできるか、直接またはグループ経由で このパネルに行があること。

言い換えると: すでにプロジェクトで作業している人は、ここで追加の設定は不要です。このパネルはプロジェクトの 外部 の人のためのもので、viewer はいかなる場合も除外されたままです。

パーミッションのテスト

タブの一番下にある Test Permission パネルは、「このユーザーはこのパスに対してどの実効アクセスを 持つか？」に答えます。どのルールが実際に決定しているかを知る最短の方法です。

1. ユーザーとパスを選ぶ

User でアカウントを選び、Path にパスを入力します。たとえば /Content/Maps/Level01.umap です。両方が入力されるまで、ボタンは無効のままです。

2. テストを実行し、結果を読む

Test をクリックします。結果には実効レベルに加えて、判断を下した ソース と パターン が表示され、アクセスが許可または拒否される理由を理解できます。

閲覧する権限のないユーザーについては、テストは存在しないアカウントと同じ「見つかりません」を返し、アカウントの 存在を明かさないようにします。

よくある落とし穴

「何も付与していないのに読めてしまう」

これは read の既定によるもので、その人がすでにアクセスできるリポジトリの内側 でのみ 働きます。プロジェクトで作業している人にフォルダーを閉じるには、そのフォルダーに明示的な none ルールを 設定してください。

「リポジトリがその人の一覧に現れない」

その人がこのリポジトリに対して none 以外のルールを 一切 持たない間は、これは正常です。 read の既定はリポジトリそのものへのアクセスを与えません。直接または グループ 経由で、少なくとも1つの read または write ルールを付与すれば、リポジトリが現れます。ビルドを 取得するだけでよい playtester の場合、対処する場所はここではありません: ビルドへのアクセス を 参照してください。

2つのルールが矛盾する

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

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

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

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

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