サブグループ
GitLab 9.0で導入されました。
GitLabグループをサブグループにまとめることができます。サブグループを使うと
- 内部組織と外部組織を分けることができます。各サブグループは独自の可視性レベルを持つことができるため、同じ親グループの下で異なる目的のグループをホストすることができます。
- 大規模プロジェクトの整理。サブグループを使用して、ソースコードの一部に異なるアクセス権を与えることができます。
- 人々を管理し、可視性を制御します。ユーザーが所属するグループごとに異なるロールを与えることができます。
サブグループは次のことができます:
- 1つの親グループに所属。
- 多くのサブグループを持っています。
- 20レベルまでネスト可能
- 親グループに登録されたRunnerを使用:
- 親グループに設定されたシークレットは、サブグループのジョブで使用できます。
- サブグループに属するプロジェクトのメンテナーのロールを持つユーザーは、親グループに登録されているRunnerの詳細を見ることができます。
使用例:
グループのサブグループの表示
前提条件
- 非公開のネストされたサブグループを表示するには、その非公開サブグループの直接のメンバーまたは継承されたメンバーである必要があります。
グループのサブグループを表示するには:
- 左のサイドバーで、Search(検索)を選択するか、Go to(移動)を選択してグループを探します。
- サブグループとプロジェクト」タブを選択します。
- ネストしたサブグループを表示するには、階層リストでサブグループを展開します。
公開親グループ内の非公開サブグループ
階層リストで、非公開サブグループを持つ公開グループには、サブグループがあることを示すすべてのユーザー用の展開オプション({chevron-down}) があります。非公開サブグループの直接メンバまたは継承メンバでないユーザーが展開({chevron-down}) を選択すると、ネストされたサブグループは表示されません。
ネストしたサブグループの存在に関する情報を非公開にしたい場合は、非公開の親グループにのみ非公開のサブグループを追加することをお勧めします。
サブグループの作成
前提条件:
- 以下のいずれかが必要です:
- グループのサブグループを作成するには、少なくともグループのメンテナーのロールを持っている必要があります。
- 設定によって決定されるロール。これらのユーザーは、管理者がユーザー設定でグループ作成を無効にしていても、サブグループを作成できます。
subgroupname.example.io
.サブグループを作成するには
- 左側のサイドバーで「検索」を選択するか、「検索」からサブグループの親グループを探します。
- 親グループの概要ページで、右上の「New subgroup」を選択します。
- グループの作成]を選択します。
- フィールドに入力します。グループ名として使用できない予約名のリストを表示します。
- グループの作成]を選択します。
サブグループを作成できる人の変更
前提条件
- グループの設定によっては、少なくともグループのメンテナーのロールを持っている必要があります。
グループにサブグループを作成できる人を変更するには:
- グループのオーナーロールを持つユーザーとして:
- 左のサイドバーで、Search(検索)を選択するか、Go to(移動)を選択してグループを探します。
- 設定] > [全般]を選択します。
- 権限とグループ機能] を展開します。
- サブグループの作成が許可されているロールからロールを選択します。
- 変更を保存を選択します。
- 管理者として。
- 左のサイドバーで、Search を選択するか、次のページに進んでください。
- Admin Areaを選択します。
- 左サイドバーで「概要」>「グループ」を選択します。
- グループの行で「編集」を選択します。
- Allowed to create subgroupsからロールを選択します。
- 変更を保存を選択します。
詳細については、権限テーブルを参照してください。
サブグループメンバーシップ
グループにメンバーを追加すると、そのメンバーはすべてのサブグループにも追加されます。ユーザーの権限はグループの親から継承されます。
サブグループのメンバーには、次のようなものがあります:
- サブグループの直接メンバー。
- サブグループの親グループからの継承メンバー。
- サブグループの最上位グループと共有されたグループのメンバー。
メンバーのグループ権限は、以下の場合にのみ変更できます:
- グループのオーナーロールを持つユーザー。
- メンバーが追加されたグループの設定の変更。
メンバーシップの継承の決定
メンバーが親グループから権限を継承しているかどうかを確認します:
- 左のサイドバーで、Search(検索)を選択するか、Go to(移動)を選択してグループを探します。
- 管理 > メンバーを選択します。
サブグループ_4 の_例のメンバーリスト:
上のスクリーンショットでは
- 5人のメンバーがグループ_4に_アクセスできます。
- ユーザー0はグループ_4の_レポーターロールを持ち、グループ_1から_権限を継承しています:
- ユーザー0はグループ_Oneの_直接のメンバーです。
- グループ_Oneは_グループ_Fourの_上にあります。
- ユーザー 1 はグループ_Four_の開発者ロールを持っており、グループ_Two_ から権限を継承しています:
- ユーザー 0 はグループ_One_ のサブグループであるグループ_Two_ の直接のメンバーです。
- グループ_One/Twoは_グループ_Fourの_上にあります。
- ユーザー2はグループ_4の_開発者ロールを持っており、グループ_3から_権限を継承しています:
- ユーザー 0 は、グループ_2_ のサブグループであるグループ_3_ の直接のメンバーです。グループ_2は_グループ_1の_サブグループです。
- グループ_1/2/3は_グループ_4より_上の階層です。
- ユーザー3はグループ_4の_直接のメンバーです。つまり、グループ_4から_直接メンテナーのロールを得ています。
- Administratorはグループ_Fourの_オーナーロールを持っており、すべてのサブグループのメンバーです。そのため、ユーザー3と同様に、Source欄は彼らが直接のメンバーであることを示しています。
メンバは、継承されたメンバシップまたは直接メンバシップによってフィルタリングできます。
祖先グループのメンバーシップのオーバーライド
サブグループのオーナーロールを持つユーザーは、サブグループにメンバーを追加できます。
サブグループ上のユーザーに、祖先グループ上のロールよりも低いロールを与えることはできません。先祖グループ上のユーザーのロールを上書きするには、そのユーザーをより高いロールでサブグループに追加し直します。例えば
- ユーザー1がDeveloperロールでグループ_2に_追加された場合、グループ_2の_すべてのサブグループでそのロールを継承します。
- グループ_4_(_One / Two / Threeの_下)でユーザー1にメンテナーのロールを与えるには、メンテナーのロールを持つグループ_4に_再度追加します。
- ユーザー1がグループ_4から_削除されると、そのロールはグループ_2の_ロールに戻ります。彼らは、グループ_4_で再び開発者ロールを持ちます。
サブグループについて
イシューやコミット、マージリクエストでサブグループ (@<subgroup_name>
) に言及すると、そのグループの直接のメンバー全員に通知されます。サブグループの継承メンバーには通知されません。メンションはプロジェクトやグループと同じように動作し、通知するグループを選択することができます。