権限と継承

GitBook で権限がどのように機能するか、誰がコンテンツにアクセスして編集できるかを制御する方法を理解する

GitBook には柔軟な権限モデルがあり、必要に応じて権限を大きくも小さくも管理できます。GitBook の権限モデルは ロールベースの、階層的な モデルです。つまり、デフォルトを設定し、その後コンテンツの各レベルで、そのデフォルトを継承するかどうかを決定します。

権限は4つのレベルで設定できます。 組織, サイト, コレクション、および スペース.

組織のデフォルトロール

組織にメンバーを追加するときに、 そのメンバーのデフォルトロールを設定します。このロールは、権限を組織のデフォルトから継承するあらゆるコンテンツに適用されます。

権限がどのように継承されるか

GitBook の権限は上から下へ、4つのレベルを通って流れます。

• 組織 — 各メンバーに設定されたデフォルトロール

• サイト — docs サイトに設定された権限。継承モードのすべてのリンク済みスペースに適用されます

• コレクション — コレクションに設定された権限。コレクション内のすべてのスペースに適用されます

• スペース — 権限を直接設定できるベースレベル

スペースが継承モードにある場合、各メンバーには 最も高いロール が、適用可能なすべてのレベルの中から割り当てられます。たとえば、あるメンバーが組織レベルでは Creator、サイトレベルでは Commenter の場合、そのスペースでは Creator の権限が維持されます。

これが実際にどのように機能するか、2つの例を示します。

例 1

あるメンバーは組織レベルで Creator ロールを持っています。あるスペースは継承モードで、誰かがサイト権限を Commenter に設定します。Creator は Commenter より高いので、そのメンバーはそのスペースで Creator 権限を保持します。組織内の他の人も既存のロールを維持します。ただし Reader は、Commenter のほうが Reader より高いため、Commenter に引き上げられます。

例 2

あるコレクションには Reader 権限があり、5人のメンバーが明示的に Creator に設定されています。そのコレクション内のスペースは継承モードで、誰かがサイト権限を Commenter に設定します。Commenter はコレクションの Reader 権限より高いため、組織内の全員がそのスペースでは Commenter に昇格します。名前付きの5人の Creator は、Creator のほうが Commenter より高いため、Creator 権限を保持します。

注： サイト権限は、継承モードのスペースにのみ適用されます。スペースに独自の権限が設定されている場合、つまり継承モードではない場合は、それが優先され、サイトレベルの権限は影響しません。

継承の管理

コレクションやスペースを作成するたびに、希望する継承タイプを設定できます。コンテンツの継承を設定するときには、大きく分けて3つの選択肢があります。

継承する

継承を 継承する に設定すると、スペースまたはコレクションは 親レベルのコンテンツに割り当てられたロールを継承します。最上位のスペースまたはコレクションの場合、この親は組織になるため、組織のデフォルトロールを継承します。コレクション内のスペースやサブコレクションの場合、親はそのコンテンツが属するコレクションになります。

スペースがサイトにリンクされている場合、サイト権限も継承ロールに反映されます。各メンバーには、組織ロール、サイト権限、コレクションレベルの権限の中で最も高いロールが付与されます。

特定ロールのアクセス

コレクションまたはスペースの権限継承を設定するときに特定のロールを選択すると、 リセットし 組織のデフォルトロールを無効化して、 非管理者 全員にそのコレクションまたはスペース内でそのロールを割り当てます。たとえば、継承を readerに設定すると、デフォルトロールに関係なく、組織内の全員がそのスペースまたはコレクションに対して閲覧のみのアクセス権を持つことになります。

ここでも最も高いロールの原則は適用されることに注意してください。別のレベル（たとえばスペースに直接設定されている、またはチームの上書き設定経由）でより高いロールが設定されている場合、その高いロールが維持されます。

アクセスなし

また、スペースまたはコレクションのレベルで、管理者以外の組織メンバーからのアクセスを完全に取り消すこともできます。これにより、管理者と、そのスペースまたはコレクションを作成した人以外にはコンテンツが表示されなくなります。

新しく作成されたスペースまたはコレクションのデフォルトの継承オプションは 継承するです。これは、コンテンツが作成されるたびに、デフォルトで親から権限を継承することを意味します。

コンテンツ固有の権限を設定する

スペースまたはコレクションの権限継承を決めたら、チームまたはメンバーに 直接アクセス.

チームに直接アクセスを付与する

特定のロールを指定して、チームをコレクションまたはスペースに直接追加できます。これにより、そのチームの全員が、そのコンテンツに対して指定されたアクセス権を得ます。

チームアクセスは、適切な人に適切なコンテンツへのアクセスを確実に与える優れた方法です。誰かがチームに追加されたり、チームから削除されたりすると、その人はそれぞれ、そのコンテンツに設定された権限を取得したり失ったりします。

メンバーに直接アクセスを付与する

チームと同様に、メンバーにも直接アクセスを付与できます。これは権限管理の中で最も細かい方法です。単一のメンバーにコレクションまたはスペースへの直接アクセスを付与すると、そのメンバーが持つ可能性のある継承権限は上書きされます。共同作業者に対して非常に具体的な制御が必要な場合、メンバーへの直接アクセスは非常に便利です。

スペースレベルで直接アクセスを持つメンバーは、継承パターンから完全に除外されます。ロールは明示的に設定され、組織、サイト、コレクションレベルの権限の影響を受けません。

権限を常に把握する

最初はかなり複雑に見えるかもしれませんが、GitBook の権限モデルは、必要なときには管理でき、不要なときには意識しなくて済むように設計されています。多くのチームでは、 設定したらあとは放置 の権限管理アプローチで十分です。別のチーム、特に大規模な組織では、アクセスとワークフローをここまで制御することが不可欠です。

設定したらあとは放置

チームメイトを招待して、一緒にコンテンツを編集できればよいだけなら、権限を確認する必要すらないかもしれません。人を招待し、デフォルトロールを設定すれば、作成するあらゆるコンテンツはこれらのロールを継承するのがデフォルトになります。細かいことまで気にする必要はありません。

アクセスとワークフローの制御

より大規模な組織、組織を複数のコレクションに分けているチーム、またはワークフローを非常に細かく制御する必要があるチームでは、細部まで把握することこそが必要です。継承、上書き、チームへの直接アクセス、ユーザーへの直接アクセスを組み合わせることで、制御を維持しながらワークフローとアクセスモデルを作成できます。