プロジェクトとグループを共有する
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
招待によって次を共有できます:
- グループとのプロジェクト。
- 別のグループとのグループ。
プロジェクトを共有する
グループにプロジェクトへのアクセスを許可する場合は、グループをプロジェクトに招待できます。グループの直接メンバーと継承されたメンバーはプロジェクトへのアクセス権を取得し、プロジェクトはshared project(共有プロジェクト)になります。
この場合、継承されたメンバーとは、親グループから招待されたグループに継承されたメンバーのことです。共有プロジェクトへのアクセス権を取得できるのは、招待されたグループのメンバーのみです。招待するグループのサブグループのメンバーにプロジェクトへのアクセス権を付与する場合は、サブグループを招待する必要があります。
次のテーブルに、共有プロジェクトへのアクセス権を取得するグループメンバーの概要を示します。
| グループメンバーのソース | 共有プロジェクトへのアクセス |
|---|---|
| 招待されたグループの直接メンバー | はい |
| 招待されたグループの継承されたメンバー | はい |
| 招待されたグループの共有メンバー1 | はい |
| サブグループの直接メンバー。ただし、招待されたグループのメンバーではない | いいえ |
| サブグループの継承されたメンバー。ただし、招待されたグループのメンバーではない | いいえ |
Footnotes(補足説明):
- GitLabは共有グループのメンバーへのプロジェクトアクセス権の拡張をサポートしていますが、この方法は推奨されていません。エピック122では、この動作の変更と、チームモデルに移行してグループを共有することが提案されています。
招待するグループの表示レベルを、プロジェクトよりも制限的にすることはできません。たとえば、次のように招待できます:
- 非公開グループを非公開プロジェクトに招待する。
- 非公開グループをinternal(内部)プロジェクトに招待する。
- 非公開グループをpublic(パブリック)プロジェクトに招待する。
- internal(内部)グループをinternal(内部)プロジェクトに招待する。
- internal(内部)グループをpublic(パブリック)プロジェクトに招待する。
- public(パブリック)グループをpublic(パブリック)プロジェクトに招待する。
プロジェクトのトップレベルグループが、階層外でプロジェクトを共有することを許可していない場合、招待されたグループまたはサブグループは、プロジェクトのネームスペースに存在している必要があります。
メンバーのアクセスとロール
グループをプロジェクトに招待すると、次のメンバーがプロジェクトへのアクセス権を取得します:
- 直接グループメンバー。
- 継承されたグループメンバー。
- 招待されたグループと共有されている他のグループのメンバー。
各メンバーのアクセス権は以下に依存します:
- グループでのロール。
- グループを招待するときに選択する最大のロール。
招待されたメンバーは、これら2つのロールのうち低い方を保持します。たとえば、メンバーがグループ内でゲストロールを持っていて、そのグループをメンテナーの最大ロールがあるプロジェクトに追加した場合、メンバーは、プロジェクト内でゲストロールを保持します。
さらに、次のようになります:
- グループのページでは、プロジェクトは共有プロジェクトタブにリストされています。
- プロジェクトのメンバーページでは、グループはグループタブにリストされています。このリストには、パブリックグループとプライベートグループの両方が含まれています。
- プロジェクトのメンバーページでは、招待されたグループのメンバーはメンバータブにリストされています。
- 使用量クォータページでは、プロファイルの横にProject Invite(プロジェクト招待)バッジが付いているメンバーは、共有プロジェクトのトップレベルグループの請求対象メンバーとしてカウントされます。
GitLab 16.11以降では、招待されたグループの名前とメンバーシップソースは、メンバータブとグループタブでマスクされます。ただし、次のいずれかに該当する場合を除きます:
- 招待グループが公開されている。
- 現在のユーザーが、招待されたグループのメンバーである。
- 現在のユーザーは、プロジェクトのオーナーです。
招待されたグループの名前とメンバーシップソースは、招待されたグループへのアクセス権を持たないメンバーからはマスクされます。プロジェクトオーナーは、招待されたグループのメンバーシップの詳細を確認して、プロジェクトへのアクセスを管理できます。
例
ネームスペースgroup/subgroup01/projectのプロジェクトの場合:
group/subgroup02またはgroup/subgroup01/subgroup03と共有できます。- プロジェクトのトップレベルグループが階層外でプロジェクトを共有することを許可していない場合を除き、
group_abcと共有できます。
Group 1によって作成されたプロジェクトの場合:
Group 1のメンバーは、プロジェクトへのアクセス権を持っています。Group 1のオーナーは、Group 2をプロジェクトに招待できます。これにより、Group 1とGroup 2の両方のメンバーが、共有プロジェクトへのアクセス権を持つようになります。
プロジェクトへグループを招待する
前提要件:
- プロジェクトのオーナーロールが必要です。
- 他のグループとのプロジェクトの共有が禁止されていない状態である必要があります。
- 招待されたグループまたはサブグループのメンバーである必要があります。
グループをプロジェクトに招待するには、次の手順に従います:
左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
管理 > メンバーを選択します。
グループを招待を選択します。
招待するグループを選択リストで、招待するグループを選択します。
最大のロールを選択リストから、招待されたグループのメンバーがプロジェクト内で持つことができるロールを選択します。招待されたメンバーは、以下のうち低い方のロールを受け取ります:
- 選択した最大ロール
- グループでの既存のロール
招待されたグループのメンバーは、グループ内で持っているロールよりも高いロールをプロジェクト内で持つことはできません。詳細については、メンバーのアクセスとロールを参照してください。
オプション。アクセス有効期限を選択します。その日以降、招待されたグループはプロジェクトにアクセスできなくなります。
招待を選択します。
招待されたグループがグループタブに表示されます。REST APIを使用してプロジェクトの招待グループを一覧表示することもできます。
プライベートグループは次のとおりです:
- 承認されていないユーザーからマスクされます。
- 保護ブランチ、保護タグ、保護環境のプロジェクト設定に表示されます。
メンバータブには、次が表示されます:
- プロジェクトに直接追加されたメンバー。
- プロジェクトが追加されたグループネームスペースの継承されたメンバー。
招待されたグループのメンバーは、webui_members_inherited_users機能フラグが有効になっていない限り、メンバータブには表示されません。
例
名前がproject-01のプロジェクトには、次の直接メンバーがいます:
- ユーザーA、オーナー
- ユーザーB、メンテナー
名前がgroup-01のグループには、次の直接メンバーがいます:
- ユーザーC、オーナー
- ユーザーD、メンテナー
- ユーザーE、レポーター
group-01がproject-01にDeveloper権限で招待されると、ユーザーは次のロールを持ちます:
- ユーザーA、オーナー
- ユーザーB、メンテナー
- ユーザーC、デベロッパー
- ユーザーD、デベロッパー
- ユーザーE、レポーター
group-01がproject-01にOwner権限で招待されると、ユーザーは次のロールを持ちます:
- ユーザーA、オーナー
- ユーザーB、メンテナー
- ユーザーC、オーナー
- ユーザーD、メンテナー
- ユーザーE、レポーター
共有プロジェクトを表示する
共有プロジェクトとは、グループを招待アクションを通じてグループメンバーにリソースへのアクセスを招待したプロジェクトのことです。
グループとアクセス権を共有しているプロジェクトを表示するには、次の手順に従います:
- 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
- グループページで、共有プロジェクトタブを選択します。
共有プロジェクトのリストが表示されます。REST APIを使用して、グループの共有プロジェクトをリスト表示することもできます。
プロジェクトがグループと共有されないようにする
別のグループとプロジェクトを共有すると、プロジェクトにさらに多くのメンバーを招待できるユーザーの数が増えます。各(サブ)グループは、アクセス権限の追加ソースになる可能性があります。したがって、混乱しやすく、制御が難しくなる場合があります。
プロジェクトが他のグループと共有されないようにするには、次の手順に従います:
- 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
- 設定 > 一般を選択します。
- 権限とグループ機能セクションを展開します。
- Projects in
<group_name>cannot be shared with other groups(のプロジェクトを他のグループと共有できません)を選択します。 - 変更を保存を選択します。
この設定を有効にすると、次のようになります:
- グループオーナーによってオーバーライドされない限り、すべてのサブグループに適用されます。
- プロジェクトに既に追加されているグループは、プロジェクトへのアクセス権を失います。
この設定を無効にした場合:
- この設定は、このグループのみに適用され、そのサブグループには適用されません。
- この設定をすべてのサブグループに対して無効にするには、各サブグループを個別に更新する必要があります。
グループのユーザー上限を指定するか、制限付きアクセスをオンにした場合、この設定を無効にすることはできません。
グループを共有する
別のグループのメンバーに自分のグループへのアクセスを許可する場合は、グループを自分のグループに招待できます。グループの直接メンバーはグループへのアクセス権を取得し、グループはshared group(共有グループ)になります。
招待されたグループの直接メンバーのみが、共有グループへのアクセス権を取得できます。継承されたメンバー、共有メンバー、またはサブグループメンバーはアクセスできません。サブグループメンバーにアクセスを許可するには、サブグループを直接招待します。
次のテーブルに、共有グループへのアクセス権を取得するグループメンバーの概要を示します:
| グループメンバーのソース | 共有グループへのアクセス |
|---|---|
| 招待されたグループの直接メンバー | はい |
| 招待されたグループの継承されたメンバー | いいえ |
| 招待されたグループの共有メンバー | いいえ |
| サブグループのメンバー。ただし、招待されたグループのメンバーではない | いいえ |
メンバーのアクセスとロール
各メンバーのアクセス権は以下に依存します:
- 招待されたグループでのロール。
- グループを招待するときに選択する最大のロール。
招待されたメンバーは、これら2つのロールのうち低い方を保持します。たとえば、メンバーがグループ内でゲストロールを持っていて、そのグループをメンテナーの最大ロールがある別のグループに招待した場合、メンバーは、新しいグループ内でゲストロールを保持します。
グループをグループに招待した後は、次のようになります:
- グループの概要ページで、このグループと共有されているグループは共有グループタブにリストされています。
- グループのメンバーページでは、招待されたグループがグループタブにリストされます。このリストには、パブリックグループとプライベートグループの両方が含まれています。
- グループのメンバーページでは、招待されたグループのメンバーがメンバータブにリストされます。
- グループの使用量クォータページでは、プロファイルの横にGroup Invite(グループ招待)バッジが付いている招待されたグループの直接メンバーは、招待グループの請求対象メンバーとしてカウントされます。
GitLab 16.11以降では、招待されたグループの名前とメンバーシップソースは、メンバータブとグループタブでマスクされます。ただし、次のいずれかに該当する場合を除きます:
- 招待グループが公開されている。
- 現在のユーザーが、招待されたグループのメンバーである。
- 現在のユーザーは、プロジェクトのオーナーです。
招待されたグループの名前とメンバーシップソースは、招待されたグループへのアクセス権を持たないメンバーからはマスクされます。ただし、グループオーナーがプライベート招待グループにアクセスできない場合でも、プライベート招待グループメンバーのソースを確認できます。この動作は、グループオーナーが所有するグループのメンバーシップをより適切に管理できるようにすることを目的としています。
例
User AはGroup 1の直接メンバーであり、グループのメンテナーロールを持っています。Group 2は、デベロッパーロールでGroup 1を招待します。User AはGroup 2でデベロッパーロールを持っています。
User Bは、Group 1の継承されたメンバーです。Group 1が招待されても、このユーザーはGroup 2へのアクセス権を取得できません。
グループにグループを招待する
グループをプロジェクトに招待する方法と同様に、グループを別のグループに招待できます。
前提要件:
- 他のユーザーを招待するには、招待するグループのオーナーロールが必要です。
- 招待するグループにアクセスできる必要があります。
グループを自分のグループに招待するには、次の手順に従います:
左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
管理 > メンバーを選択します。
グループを招待を選択します。
招待するグループを選択リストで、招待するグループを選択します。
最大のロールを選択リストから、招待されたグループのメンバーがグループ内で持つことができるロールを選択します。招待されたメンバーは、以下のうち低い方のロールを受け取ります:
- 選択した最大ロール
- 招待されたグループでの既存のロール
招待されたメンバーは、招待されたグループ内で持っているロールよりも高いロールを持つことはできません。詳細については、メンバーのアクセスとロールを参照してください。
オプション。アクセス有効期限を選択します。その日以降、招待されたグループはグループにアクセスできなくなります。
招待を選択します。
招待されたグループを削除する
招待されたグループを削除するには、次の手順に従います:
- 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
- 管理 > メンバーを選択します。
- グループタブを選択します。
- 削除するグループの右側にあるグループを削除する( )を選択します。
招待されたグループを自分のグループから削除すると、次のようになります:
- 招待されたグループのすべての直接メンバーは、自分のグループへのアクセス権を持たなくなります。
- 招待されたグループのメンバーは、グループの請求可能メンバーとしてカウントされなくなります。
共有グループを表示する
共有グループとは、グループを招待アクションを通じてグループメンバーにリソースへのアクセスを招待したグループのことです。
グループとアクセス権を共有しているグループを表示するには、次の手順に従います:
- 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
- グループページで、共有グループタブを選択します。
共有グループのリストが表示されます。REST APIを使用してグループの共有グループをリスト表示することもできます。
グループ階層外へのグループの招待を禁止する
トップレベルグループのサブグループとプロジェクトが、トップレベルグループの階層外の他のグループを招待できないように、トップレベルグループを設定できます。このオプションは、トップレベルグループでのみ利用できます。
たとえば、次のようなグループとプロジェクトの階層があるとします:
- Animals(動物) > Dogs(犬) > Dog Project(犬プロジェクト)
- Animals(動物) > Cats(猫)
- Plants(植物) > Trees(木)
この際、Animals(動物)グループの階層外へのグループの招待を禁止した場合、次のようになります:
- Dogs(犬)はCats(猫)グループを招待できます。
- Dogs(犬)はTrees(木)グループを招待できません。
- Dog Project(犬プロジェクト)はCats(猫)グループを招待できます。
- Dog Project(犬プロジェクト)はTrees(木)グループを招待できません。
グループの階層外へのグループの招待を禁止するには、次の手順を実行します:
- 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
- 設定 > 一般を選択します。
- 権限とグループ機能を展開します。
- Members cannot invite groups outside of
<group_name>and its subgroups(メンバーは、とそのサブグループ以外のグループを招待できません)を選択します。 - 変更を保存を選択します。
コラボレーションのためにグループを設定する
グループ内のプロジェクトで外部ユーザーとコラボレーションする場合は、次のベストプラクティスを検討してください:
- 組織のニーズに基づいて、グループとサブグループを論理的に構成します。不要なグループの作成は避けてください。
- 管理するユーザーが多い場合は、プロジェクトを編成するグループとは別に、ユーザーをグループに編成することを検討してください。これらのユーザーグループを、アクセスする必要があるグループとプロジェクトに共有します。
- プロジェクトに招待するグループを慎重に検討してください。共有の過剰を防ぎ、セキュリティを維持するために、アクセスする必要のあるグループのみを招待してください。
- グループを招待する場合は、次を行ってください:
- 最大のロールを適切に設定します。最高のロールをデフォルトにするのではなく、必要な最小限の権限を割り当てることをお勧めします。
- 招待されたグループのサブグループのメンバーに、プロジェクトへのアクセス権を付与しないようにします。代わりに、サブグループを個別に招待することをお勧めします。
- プロジェクトへのアクセス権限を持つ複数のグループに所属するユーザーの最大ロールを確認してください。意図しない高い権限を防ぐために、ユーザーのロールを変更することをお勧めします。
- 共有プロジェクトへのグループアクセスを定期的に確認し、必要に応じて更新してください。グループがプロジェクトへのアクセスを必要としなくなった場合は、削除します。