権限と継承

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

GitBook には柔軟な権限モデルがあり、必要に応じて権限を細かくも、あるいは最小限にも制御できます。GitBook の権限モデルは ロールベースの、段階的な モデルです。つまり、既定値を設定し、その後、コンテンツのどの階層でも、その既定値を継承するかどうかを決められます。

権限は次の 4 つの階層で設定できます： 組織, サイト, コレクション、そして スペース.

組織のデフォルトロール

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

権限の継承の流れ

GitBook の権限は 優先順位によって解決され、すべての階層で最も高いロールで決まるわけではありません。

継承モードのスペースでは、GitBook は次の順序でアクセス権を解決します：

• スペース — スペース上のメンバーおよびチームの直接上書き

• サイト — 親サイトの権限

• コレクション — 親コレクションの権限（存在する場合）

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

つまり、継承モードのリンク済みスペースでは、サイトの権限が組織のデフォルトと親コレクションのデフォルトを上書きします。スペースレベルの直接上書きは、それでも他のすべてより優先されます。

実際には、次の 2 つの例のようになります：

例 1

あるメンバーに組織レベルで Creator ロールが付与されています。リンクされたスペースが継承モードになっており、親サイトでそのメンバーは Commenter に設定されています。サイトが組織のデフォルトより優先されるため、そのメンバーはそのスペースで Commenter アクセスを得ます。

例 2

コレクションでスペースを Reader に設定し、親サイトでそれを Commenter に設定したとします。継承モードではサイトの権限が親コレクションより優先されるため、そのスペースでは Commenter が使われます。さらに、そのスペースで 1 人のメンバーに直接 Creator アクセスを付与すると、そのメンバーに対してはその直接上書きが優先されます。

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

継承の管理

コレクションやスペースを作成するたびに、希望する継承の種類を設定できます。コンテンツの継承を設定する際には、次の 3 つの大きな選択肢があります：

継承

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

スペースがサイトにリンクされ、継承モードのままの場合、GitBook はアクセス権を次の順で解決します。スペースの直接上書き、次に親サイト、次に親コレクション、最後に組織です。サイトの権限は組織とコレクションのデフォルトより優先されますが、スペースレベルの直接上書きは変更しません。

特定ロールのアクセス

コレクションまたはスペースの権限継承を設定するときに特定のロールを選択すると、 リセットし 組織のデフォルトロールが適用され、すべての 管理者以外の ユーザーに、コレクションまたはスペース内でそのロールを割り当てます。たとえば、継承を Readerに設定すると、組織内の全員が、そのデフォルトロールに関係なく、そのスペースまたはコレクションに対して読み取り専用アクセスになります。

そのコレクションまたはスペースに対するメンバーやチームの直接アクセスは、この継承設定を上書きできます。スペース自体に特定のロールを設定した場合、そのスペースはもはや継承モードを使用しないため、サイトの権限は影響しません。

アクセスなし

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

新しく作成されたスペースまたはコレクションの既定の継承オプションは 継承です。つまり、コンテンツが作成されるたびに、既定では親から権限を継承します。

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

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

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

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

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

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

チームと同様に、メンバーにも直接アクセスを付与できます。これは権限を管理するうえで最もきめ細かな方法です。個々のメンバーにコレクションまたはスペースへの直接アクセスを与えると、そのメンバーが持つ可能性のある継承済みの権限は上書きされます。共同作業者を非常に細かく制御したい場合には、メンバーの直接アクセスが最適です。

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

権限を常に把握する

最初はかなり複雑に見えるかもしれませんが、GitBook の権限モデルは、必要なときには制御でき、不要なときには手を煩わせません。多くのチームにとっては、 設定して放置する 権限管理のアプローチだけで十分です。別のチーム、特に大規模な組織では、アクセスとワークフローをここまで細かく制御できることが不可欠です。

設定して放置

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

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

大規模な組織や、組織を個別のコレクションに分けているチーム、あるいはワークフローを非常に細かく制御する必要があるチームでは、細部に踏み込むことこそがまさに必要です。継承、上書き、チームへの直接アクセス、ユーザーへの直接アクセスを組み合わせることで、制御を保ちながらワークフローとアクセスモデルを構築できます。