プロジェクトとグループを共有する
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
招待によって次を共有できます。
- グループとのプロジェクト。
- 別のグループとのグループ。
プロジェクトを共有する
グループにプロジェクトへのアクセスを許可する場合は、グループをプロジェクトに招待できます。グループの直接メンバーと継承されたメンバーはプロジェクトへのアクセス権を取得し、プロジェクトは共有プロジェクトになります。
この場合、継承されたメンバーとは、親グループから招待されたグループに継承されたメンバーのことです。共有プロジェクトへのアクセス権を取得できるのは、招待されたグループのメンバーのみです。招待するグループのサブグループのメンバーにプロジェクトへのアクセス権を付与する場合は、サブグループを招待する必要があります。
次のテーブルに、共有プロジェクトへのアクセス権を取得するグループメンバーの概要を示します。
| グループメンバーのソース | 共有プロジェクトへのアクセス |
|---|---|
| 招待されたグループの直接メンバー | |
| 招待されたグループの継承されたメンバー | |
| 招待されたグループの共有メンバー1 | |
| サブグループの直接メンバー。ただし、招待されたグループのメンバーではない | いいえ |
| サブグループの継承されたメンバー。ただし、招待されたグループのメンバーではない | いいえ |
脚注:
- GitLabは共有グループのメンバーへのプロジェクトアクセス権の拡張をサポートしていますが、この方法は推奨されていません。エピック122では、この動作の変更と、チームモデルに移行してグループを共有することが提案されています。
招待するグループの表示レベルは、プロジェクトよりも制限が厳しいものであってはなりません。たとえば、次のように招待できます。
- プライベートグループをプライベートプロジェクトに招待する。
- プライベートグループを内部プロジェクトに招待する。
- プライベートグループをパブリックプロジェクトに招待する。
- 内部グループを内部プロジェクトに招待する。
- 内部グループをパブリックプロジェクトに招待する。
- パブリックグループをパブリックプロジェクトに招待する。
プロジェクトのトップレベルグループが、階層外でプロジェクトを共有することを許可していない場合、招待されたグループまたはサブグループは、プロジェクトのネームスペースに存在している必要があります。
メンバーのアクセスとロール
グループをプロジェクトに招待すると、次のメンバーがプロジェクトへのアクセス権を取得します。
- 直接グループメンバー。
- 継承されたグループメンバー。
- 招待されたグループと共有されている他のグループのメンバー。
各メンバーのアクセス権は以下に依存します。
- グループでのロール。
- グループを招待するときに選択する最大のロール。
招待されたメンバーは、これら2つのロールのうち低い方を保持します。たとえば、メンバーがグループ内でゲストロールを持っていて、そのグループをメンテナーの最大ロールがあるプロジェクトに追加した場合、メンバーは、プロジェクト内でゲストロールを保持します。
さらに、次のようになります。
- グループのページでは、プロジェクトは共有プロジェクトタブにリストされています。
- プロジェクトのメンバーページでは、グループはグループタブにリストされています。このリストには、パブリックグループとプライベートグループの両方が含まれています。
- プロジェクトのメンバーページでは、招待されたグループのメンバーはメンバータブにリストされています。
- 使用量クォータページでは、プロファイルの横にプロジェクト招待バッジが付いているメンバーは、共有プロジェクトのトップレベルグループの請求対象メンバーとしてカウントされます。
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を使用して、グループの共有プロジェクトをリスト表示することもできます。
プロジェクトがグループと共有されないようにする
別のグループとプロジェクトを共有すると、プロジェクトにさらに多くのメンバーを招待できるユーザーの数が増えます。各（サブ）グループは、アクセス権限の追加ソースになる可能性があります。したがって、混乱しやすく、制御が難しくなる場合があります。
プロジェクトが他のグループと共有されないようにするには、次の手順に従います。
- 上部のバーで、検索または移動先を選択して、グループを見つけます。
- 設定 > 一般を選択します。
- 権限とグループ機能セクションを展開します。
<group_name>のプロジェクトを他のグループと共有できませんを選択します。- 変更を保存を選択します。
この設定を有効にすると、次のようになります。
- グループオーナーによってオーバーライドされない限り、すべてのサブグループに適用されます。
- プロジェクトに既に追加されているグループは、プロジェクトへのアクセス権を失います。
この設定が無効になっている場合:
- これは、このグループにのみ適用され、そのサブグループには適用されません。
- すべてのサブグループでこの設定を無効にするには、各サブグループを個別に更新する必要があります。
グループを共有する
別のグループのメンバーに自分のグループへのアクセスを許可する場合は、グループを自分のグループに招待できます。グループの直接メンバーはグループへのアクセス権を取得し、グループは共有グループになります。
招待されたグループの直接メンバーのみが、共有グループへのアクセス権を取得できます。継承されたメンバー、共有メンバー、またはサブグループメンバーはアクセスできません。サブグループメンバーにアクセスを許可するには、サブグループを直接招待します。
次のテーブルに、共有グループへのアクセス権を取得するグループメンバーの概要を示します。
| グループメンバーのソース | 共有グループへのアクセス |
|---|---|
| 招待されたグループの直接メンバー | |
| 招待されたグループの継承されたメンバー | いいえ |
| 招待されたグループの共有メンバー | いいえ |
| サブグループのメンバー。ただし、招待されたグループのメンバーではない | いいえ |
メンバーのアクセスとロール
各メンバーのアクセス権は以下に依存します。
- 招待されたグループでのロール。
- グループを招待するときに選択する最大のロール。
招待されたメンバーは、これら2つのロールのうち低い方を保持します。たとえば、メンバーがグループ内でゲストロールを持っていて、そのグループをメンテナーの最大ロールがある別のグループに招待した場合、メンバーは、新しいグループ内でゲストロールを保持します。
グループをグループに招待した後は、次のようになります。
- グループの概要ページで、このグループと共有されているグループは共有グループタブにリストされています。
- グループのメンバーページでは、招待されたグループがグループタブにリストされます。このリストには、パブリックグループとプライベートグループの両方が含まれています。
- グループのメンバーページでは、招待されたグループのメンバーがメンバータブにリストされます。
- グループの使用量クォータページでは、プロファイルの横にグループ招待バッジが付いている招待されたグループの直接メンバーは、招待グループの請求対象メンバーとしてカウントされます。
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
この際、動物グループの階層外へのグループの招待を禁止した場合、次のようになります。
- 犬は猫グループを招待できます。
- 犬は木グループを招待できません。
- 犬プロジェクトは猫グループを招待できます。
- 犬プロジェクトは木グループを招待できません。
グループの階層外へのグループの招待を禁止するには、次の手順を実行します。
- 上部のバーで、検索または移動先を選択して、グループを見つけます。
- 設定 > 一般を選択します。
- 権限とグループ機能を展開します。
- メンバーは、
<group_name>とそのサブグループ以外のグループを招待できませんを選択します。 - 変更を保存を選択します。
コラボレーションのためにグループを設定する
グループ内のプロジェクトで外部ユーザーとコラボレーションする場合は、次のベストプラクティスを検討してください。
- 組織のニーズに基づいて、グループとサブグループを論理的に構成します。不要なグループの作成は避けてください。
- 管理するユーザーが多い場合は、プロジェクトを編成するグループとは別に、ユーザーをグループに編成することを検討してください。これらのユーザーグループを、アクセスする必要があるグループとプロジェクトに共有します。
- プロジェクトに招待するグループを慎重に検討してください。共有の過剰を防ぎ、セキュリティを維持するために、アクセスする必要のあるグループのみを招待してください。
- グループを招待する場合は、次を行ってください。
- 最大のロールを適切に設定します。最高のロールをデフォルトにするのではなく、必要な最小限の権限を割り当てることをお勧めします。
- 招待されたグループのサブグループのメンバーに、プロジェクトへのアクセス権を付与しないようにします。代わりに、サブグループを個別に招待することをお勧めします。
- プロジェクトへのアクセス権限を持つ複数のグループに所属するユーザーの最大ロールを確認してください。意図しない高い権限を防ぐために、ユーザーのロールを変更することをお勧めします。
- 共有プロジェクトへのグループアクセスを定期的に確認し、必要に応じて更新してください。グループがプロジェクトへのアクセスを必要としなくなった場合は、削除します。