権限とロール

プロジェクトやグループにユーザーを追加すると、そのユーザーにロールが割り当てられます。ロールによって、GitLabでどのアクションができるかが決まります。

ユーザーをプロジェクトのグループとプロジェクトの両方に追加した場合は、上位のロールが使われます。

GitLab管理者は全ての権限を持ちます。

ロール

利用可能なロールは以下の通りです:

Guestロールを割り当てられたユーザーは最小限の権限を持ち、オーナーは最大の権限を持ちます。

デフォルトでは、全てのユーザーがトップレベルのグループを作成し、ユーザー名を変更することができます。GitLab管理者はGitLabインスタンスに対してこの動作を変更することができます。

プロジェクトメンバーの権限

  • GitLab 14.8で導入され、個人の名前空間のオーナーは、その名前空間の新しいプロジェクトでOwnerロールで表示されます。personal_project_owner_with_owner_accessというフラグで導入されました。デフォルトでは無効になっています。
  • GitLab 14.9で一般的に利用可能に。機能フラグpersonal_project_owner_with_owner_access削除しました。

ユーザーのロールによって、プロジェクトに対する権限が決まります。オーナーロールはすべての権限を提供しますが、プロジェクトでのみ利用可能です:

  • グループとプロジェクトのオーナー。GitLab 14.8以前では、ロールはグループのプロジェクトに継承されます。
  • 管理者の場合。

個人ネームスペースのオーナー:

  • 名前空間内のプロジェクトでメンテナーのロールを持つものとして表示されますが、Owner ロールを持つユーザーと同じ権限を持ちます。
  • GitLab 14.9以降では、ネームスペース内の新規プロジェクトでは、オーナーロールを持つものとして表示されます。

プロジェクトメンバーの管理方法については、プロジェクトのメンバーを参照してください。

以下の表は、各ロールで利用可能なプロジェクト権限の一覧です:

アクションゲストレポーター開発者メンテナーオーナー
アナリティクス:
イシューのアナリティクスを見る
分析:
価値ストリーム分析を表示
アナリティクス
DORAメトリクスを見る
 
アナリティクス:
CI/CDアナリティクスを見る
 
アナリティクス:
コードレビューのアナリティクスを表示します。
 
分析:
マージリクエスト分析を見る
 
アナリティクス
リポジトリのアナリティクスを表示します。
 
アプリケーションセキュリティ:
依存関係リストのライセンスの表示
  
アプリケーションセキュリティ:
オンデマンドDASTスキャンの作成と実行
  
アプリケーションセキュリティ
セキュリティポリシーの管理
  
アプリケーション・セキュリティ:
依存関係リストの表示
  
アプリケーションセキュリティ
CVE IDリクエストの作成
   
アプリケーションセキュリティ:
セキュリティポリシープロジェクトの作成または割り当て
    
GitLab Agent for Kubernetes:
ビューエージェント
  
GitLab Agent for Kubernetes:
エージェントの管理
   
コンテナレジストリ
クリーンアップポリシーの作成、編集、削除
   
コンテナレジストリ
コンテナレジストリにイメージをプッシュします。
  
コンテナレジストリ
コンテナレジストリからイメージを取り出します。
✓ (19)✓ (19)
コンテナレジストリ
コンテナレジストリイメージの削除
  
GitLab Pages:
アクセスコントロールで保護された Pages を表示します。
GitLab Pages:
管理
   
GitLab Pages:
GitLab Pages のドメインと証明書を管理します。
   
GitLab Pages:
GitLab Pages を削除してください。
   
インシデント管理:
アラートの割り当て
インシデント管理
オンコールローテーションへの参加
インシデント管理:
インシデントを見る
インシデント管理
アラートステータスの変更
 
インシデント管理
インシデントの重大度を変更
 
インシデント管理
インシデントの作成
 
インシデント管理
アラートの表示
 
インシデント管理:
エスカレーションポリシーの表示
 
インシデント管理:
オンコールスケジュールの表示
 
インシデント管理
インシデントのエスカレーションステータスの変更
  
インシデント管理
インシデントエスカレーション方針の変更
  
インシデント管理
オンコールスケジュールの管理
   
インシデント管理
エスカレーションポリシーの管理
   
イシューボード
リストの作成と削除
 
イシューボード:
リスト間のイシュー移動
 
イシュー
ラベルの追加
✓ (15)
イシュー
エピックに追加
 ✓ (22)✓ (22)✓ (22)✓ (22)
イシュー
アサイン
✓ (15)
イシュー
クリエイト (17)
イシュー
機密事項の作成
イシュー
デザイン管理ページを見る
イシュー
関連するイシューを見る
イシュー
セット重量
 
イシュー:
イシューの作成時に、ラベル、マイルストーン、担当者などのメタデータを設定します。
✓ (15)
イシュー:
既存のイシューのラベル、マイルストーン、担当者などのメタデータを編集します。
(15)
イシュー
セット親エピック
 
イシュー
機密事項の表示
(2)
イシュー
クローズ/再開 (18)
 
イシュー
ロックスレッド
 
イシュー
関連する問題の管理
 
イシュー
トラッカーの管理
 
イシュー
移動問題 (14)
 
イシュー:
イシューの時間追跡の見積もりと費やした時間を設定します。
 
イシュー
アーカイブデザイン管理ファイル
  
イシュー:
Design Managementファイルのアップロード
  
イシュー
削除
    
ライセンススキャン:
許可されたライセンスと拒否されたライセンスの表示
✓ (1)
ライセンススキャン:
ライセンスコンプライアンスレポートの表示
✓ (1)
ライセンススキャン:
ライセンスリストの表示
 
ライセンス承認者ポリシー:
ライセンスポリシーの管理
   
マージリクエスト:
レビュアー割り当て
 
マージリクエスト:
一覧を見る
 
マージリクエスト:
コード変更提案の適用
  
マージリクエスト:
承認者 (8)
  
マージリクエスト:
アサイン
  
マージリクエスト:
作成 (16)
  
マージリクエスト:
ラベルの追加
  
マージリクエスト:
ロックスレッド
  
マージリクエスト:
管理または承認
  
マージリクエスト:
スレッドを解決します
  
マージリクエスト:
マージ承認ルールの管理 (プロジェクト設定)
   
マージリクエスト:
削除
    
メトリクス・ダッシュボード:
ユーザーが設定したメトリクス・ダッシュボードを管理 (6)
メトリクス・ダッシュボード
メトリクス・ダッシュボードの注釈を表示します。
 
メトリクス・ダッシュボード:
メトリクス・ダッシュボードの注釈の作成/編集/削除
  
パッケージレジストリ:
パッケージをプルします。
✓ (1)
パッケージレジストリ:
パッケージの公開
  
パッケージレジストリ:
パッケージの削除
   
パッケージレジストリ:
パッケージに関連するファイルの削除
   
プロジェクトオペレーション
エラー追跡リストの表示
 
プロジェクトオペレーション
機能フラグの管理
  
プロジェクトオペレーション
エラートラッキングの管理
   
プロジェクト:
ダウンロードプロジェクト
✓ (1)
プロジェクト:
コメントを残す
プロジェクト:
画像のコメントを再配置(どのユーザーでも投稿可能)。
✓ (9)✓ (9)✓ (9)
プロジェクト
インサイトを見る
プロジェクト:
リリースを見る
✓ (5)
プロジェクト
要件を見る
プロジェクト:
タイムトラッキングレポートの閲覧
✓ (1)
プロジェクト:
Wikiページを見る
プロジェクト
スニペット作成
 
プロジェクト
ラベルの管理
 
プロジェクト:
プロジェクトのトラフィック統計を見る
 
プロジェクト
マイルストーンの作成、編集、削除。
 
プロジェクト:
リリースの作成、編集、削除
  ✓ (12)✓ (12)✓ (12)
プロジェクト:
Wikiページの作成、編集
  
プロジェクト
レビューアプリの有効化
  
プロジェクト
プロジェクト監査イベントの表示
  ✓ (10)
プロジェクト:
デプロイキーの追加
   
プロジェクト:
新しいチームメンバーの追加
   
プロジェクト
チームメンバーの管理
   ✓ (20)
プロジェクト:
プロジェクト機能の可視レベルの変更
   ✓ (13)
プロジェクト:
Webhookの設定
   
プロジェクト:
Wikiページの削除
  
プロジェクト:
コメントの編集 (どのユーザーでも投稿可能)
   
プロジェクト
プロジェクトバッジの編集
   
プロジェクト
プロジェクト設定の編集
   
プロジェクト
エクスポート・プロジェクト
   
プロジェクト:
プロジェクトアクセストークンの管理 (11)
   ✓ (20)
プロジェクト
プロジェクトオペレーションの管理
   
プロジェクト
プロジェクト名の変更
   
プロジェクト
グループでプロジェクトを共有(招待)。
   ✓ (7)✓ (7)
プロジェクト:
メンバーの2FAステータスの表示
   
プロジェクト:
コンプライアンスフレームワークへのプロジェクトの割り当て
    
プロジェクト
アーカイブ・プロジェクト
    
プロジェクト:
プロジェクトの可視性レベルの変更
    
プロジェクト:
プロジェクトの削除
    
プロジェクト:
通知メールの無効化
    
プロジェクト:
プロジェクトを別の名前空間に転送します。
    
プロジェクト利用枠のページを見る   
リポジトリ
プロジェクトコードをプルします。
✓ (1)
リポジトリ
プロジェクトコードを見る
✓ (1) (23)
リポジトリ:
コミットステータスの表示
 
リポジトリ
タグを追加
  
リポジトリ
新しいブランチを作成します。
  
リポジトリ:
コミットステータスの作成または更新
  ✓ (4)
リポジトリ
非保護ブランチへの強制プッシュ
  
リポジトリ:
非保護ブランチへのプッシュ
  
リポジトリ:
保護されていないブランチを削除します。
  
リポジトリ
Gitタグの書き換えまたは削除
  
リポジトリ
ブランチ保護の有効化または無効化
   
リポジトリ
タグ保護の有効化または無効化
   
リポジトリ
プッシュルールの管理
   
リポジトリ:
保護ブランチにプッシュ (4)
   
リポジトリ:
開発者のための保護ブランチプッシュのオン・オフを切り替えます。
   
リポジトリ
フォーク関係の削除
    
リポジトリ:
保護ブランチへの強制プッシュ (3)
     
リポジトリ:
保護されたブランチを削除 (3)
     
要件管理:
アーカイブ / 再オープン
 
要件管理
作成/編集
 
要件管理
インポート/エクスポート
 
セキュリティダッシュボード:
脆弱性の発見からイシューの作成
  
セキュリティダッシュボード
脆弱性の発見から脆弱性の作成
  
セキュリティ・ダッシュボード
脆弱性の解消
  
セキュリティダッシュボード
脆弱性の発見を却下します。
  
セキュリティダッシュボード:
脆弱性の解決
  
セキュリティダッシュボード:
脆弱性を検出された状態に戻します。
  
セキュリティダッシュボード
セキュリティダッシュボードを使用します。
  
セキュリティダッシュボード:
脆弱性の表示
  
セキュリティダッシュボード:
脆弱性の発見を依存関係リストで表示します。
  
タスク:
作成 (17)
 
タスク:
編集
 
タスク
イシューから削除
 
タスク:
削除 (21)
    
Terraform:
Terraformの状態を読む
  
Terraform:
Terraformの状態を管理します。
   
テストケース
アーカイブ
 
テストケース
作成
 
テストケース
移動
 
テストケース
再開
 
  1. セルフマネジメントの GitLab インスタンスでは、Guest ロールを持つユーザーは公開プロジェクトと内部プロジェクトでのみこのアクションを実行できます (非公開プロジェクトではできません)。プロジェクトが内部であっても、外部ユーザーには明示的なアクセス権(少なくともレポーターロール)を与える必要があります。GitLab.comでGuestロールを持つユーザーは、内部可視性が利用できないため、公開プロジェクトでのみこのアクションを実行できます。
  2. ゲストユーザーは、自分で作成した、または割り当てられた機密イシューのみを閲覧することができます。
  3. ゲスト、レポーター、開発者、メンテナー、オーナーには許可されません。保護されたブランチを参照してください。
  4. ブランチが保護されている場合は、開発者やメンテナーに与えられているアクセス権に依存します。
  5. ゲストユーザーは GitLab にアクセスできます。 リリースにアクセスしてアセットをダウンロードできますが、ソースコードをダウンロードしたり、コミットやリリースの証拠などのリポジトリ情報を見ることはできません。
  6. アクションはユーザーが所有(参照)しているレコードのみに制限されます。
  7. 共有グループロックが有効な場合、プロジェクトを他のグループと共有することはできません。グループ共有のグループには影響しません。
  8. マージリクエストの承認者については、承認者を参照してください。
  9. Design Managementデザインに対するコメントのみに適用されます。
  10. ユーザーは各自のアクションに基づくイベントのみを表示できます。
  11. プロジェクトアクセストークンは、Free以上のセルフマネージドインスタンスでサポートされています。GitLab SaaS Premium以上(トライアルライセンスを除く)でもサポートされています。
  12. タグが保護されている場合、これは開発者とメンテナーに与えられたアクセス権に依存します。
  13. プロジェクトの可視性が非公開に設定されている場合、メンテナーやオーナーはプロジェクト機能の可視性レベルを変更できません。
  14. ユーザーが開発者ロールを持っていなくても、添付されたデザインファイルがイシューと一緒に移動されます。
  15. ゲストユーザーは、課題の作成時にのみメタデータ(ラベル、担当者、マイルストーンなど)を設定できます。既存のイシューのメタデータを変更することはできません。
  16. 外部メンバーからの貢献を受け入れるプロジェクトでは、ユーザーは自分自身のマージリクエストを作成、編集、クローズすることができます。
  17. 作成者と担当者は、レポーターロールを持っていなくても、タイトルと説明を修正できます。
  18. 作成者と担当者は、レポーターのロールを持っていなくても、イシューをクローズしたり、再開することができます。
  19. コンテナレジストリの表示とイメージのプル機能は、コンテナレジストリの表示権限によって制御されます。
  20. メンテナーは、オーナーを作成、降格、削除することはできず、ユーザーをオーナーのロールに昇格させることもできません。また、Ownerロールのアクセス要求を承認することもできません。
  21. タスクの作成者はオーナーロールを持っていなくてもタスクを削除できますが、少なくともプロジェクトのゲストロールを持っている必要があります。
  22. エピックの閲覧権限が必要です。
  23. GitLab 15.9以降では、GuestロールとUltimateライセンスを持つユーザーは、管理者(セルフマネージド上)またはグループオーナー(GitLab.com上)がそれらのユーザーに権限を与えた場合、非公開リポジトリのコンテンツを閲覧することができます。管理者またはグループオーナーは、APIを通じてカスタムロールを作成し、そのロールをユーザーに割り当てることができます。

プロジェクト機能の権限

プロジェクトレベルの機能の権限についての詳細は以下の通りです。

GitLab CI/CD の権限

一部のロールに対するGitLab CI/CD権限は、これらの設定によって変更することができます:

  • 公開パイプライン:公開パイプライン: 公開に設定すると、特定の CI/CD 機能へのアクセスをゲストプロジェクトメンバーに与えます。
  • パイプラインの可視化Everyone with Accessに設定すると、プロジェクトメンバー以外でもCI/CDの特定の機能にアクセスできるようになります。
アクション非会員ゲストレポーター開発者メンテナーオーナー
アーティファクトの存在を確認✓ (3)✓ (3)
ジョブ一覧を見る✓ (1)✓ (2)
アーティファクトの表示とダウンロード✓ (1)✓ (2)
環境を見る✓ (3)✓ (3)
ジョブログとジョブ詳細ページの表示✓ (1)✓ (2)
パイプラインとパイプライン詳細ページの表示✓ (1)✓ (2)
MR の View pipelines タブ✓ (3)✓ (3)
パイプラインの脆弱性を表示 ✓ (2)
プロジェクトレベルのセキュアファイルの表示とダウンロード   
ジョブのキャンセルと再試行   
新しい環境の創造   
ジョブログまたはアーティファクトの削除   ✓ (4)
CI/CDパイプラインの実行   
保護ブランチの CI/CD パイプラインの実行   ✓ (5)✓ (5)
環境停止   
保護環境のデプロイジョブの実行  ✓ (5)✓ (6)✓ (6)
デバッグロギングでジョブを表示   
パイプラインエディターの使用   
対話型ウェブ端末の実行   
プロジェクト・ランナーをプロジェクトに追加    
ランナー・キャッシュの手動クリア    
プロジェクトで共有ランナーを有効化    
CI/CD設定の管理    
ジョブ・トリガーの管理    
プロジェクトレベルのCI/CD変数の管理    
プロジェクトレベルのセキュアファイルの管理    
環境端子の使用    
パイプラインの削除     
  1. プロジェクトが公開されていて、プロジェクト設定 > CI/CDでパブリックパイプラインが有効になっている場合。
  2. プロジェクト設定 > CI/CD公開パイプラインが有効になっている場合。
  3. プロジェクトが公開されている場合。
  4. ジョブが両方あった場合のみ:
    • ユーザーによってトリガーされました。
    • GitLab 13.0以降では、保護されていないブランチに対して実行。
  5. ユーザーが保護ブランチへのマージやプッシュを許可されている場合。
  6. ユーザーが少なくともレポーターロールを持つグループに属している場合。

ジョブ権限

この表は、特定のタイプのユーザーによってトリガーされたジョブに付与された権限を示しています:

アクションゲスト、レポーター開発者メンテナー管理者
CI ジョブの実行 
現在のプロジェクトからソースとLFSをクローン 
公開プロジェクトのクローンソースとLFS 
内部プロジェクトからのクローンソースとLFS ✓ (1)✓ (1)
非公開プロジェクトのクローンソースとLFS ✓ (2)✓ (2)✓ (2)
現在のプロジェクトからのコンテナイメージのプル 
公開プロジェクトからのコンテナイメージの取得 
内部プロジェクトからのコンテナイメージのプル ✓ (1)✓ (1)
非公開プロジェクトからのコンテナイメージのプル ✓ (2)✓ (2)✓ (2)
コンテナイメージを現在のプロジェクトにプッシュ 
コンテナイメージを他のプロジェクトにプッシュ    
ソースとLFSのプッシュ    
  1. トリガーユーザーが外部でない場合のみ。
  2. トリガーユーザーがプロジェクトのメンバーである場合のみ。プルポリシーによる非公開Dockerイメージの利用if-not-presentも参照してください。

グループメンバーの権限

グループの最後のオーナーでない限り、どのユーザーでもグループから自分を削除することができます。

次の表は、各ロールで利用可能なグループ権限の一覧です:

アクションゲストレポーター開発者メンテナーオーナー
子エピックの追加/削除✓ (8)
エピックにイシューを追加✓ (7)✓ (7)✓ (7)✓ (7)✓ (7)
グループをブラウズ
依存プロキシを使用したコンテナイメージのプル
貢献者分析を見る
エピックグループを見る
グループのWikiPagesを見る✓ (5)
インサイトを見る
インサイトチャートを見る
イシュー分析を見る
価値のストリーム分析の表示
グループエピックの作成/編集 
エピックボードの作成/編集/削除 
グループラベルの管理 
パッケージの公開  
プルパッケージ 
パッケージの削除   
Mavenおよび汎用パッケージの重複設定の作成/編集/削除   
パッケージ・リクエスト転送の有効化/無効化   
コンテナレジストリイメージのプル✓ (6)
コンテナレジストリイメージの削除  
グループのDevOps導入状況を見る 
メトリクス・ダッシュボードの注釈の表示 
生産性分析を見る 
グループWikiページの作成と編集  
グループでプロジェクト作成  ✓ (2)(4)✓ (2)✓ (2)
フォークプロジェクトをグループ化   
グループのマイルストーンの作成/編集/削除 
反復の作成/編集/削除 
メトリクス・ダッシュボードのアノテーションの作成/編集/削除  
依存プロキシの有効化/無効化   
グループの依存プロキシをパージ    
依存プロキシのクリーンアップ・ポリシーの作成/編集/削除   
セキュリティダッシュボードの使用  
グループ監査イベントの表示  ✓ (6)✓ (6)
サブグループの作成   ✓ (1)
グループWikiページの削除  
エピックコメントの編集(どのユーザーでも投稿可能)   
リストグループのデプロイトークン   
グループプッシュルールの管理   
グループレベルのKubernetesクラスターの表示/管理   
コンプライアンス・フレームワークの構築と管理    
グループデプロイトークンの作成/削除    
グループの可視レベルを変更    
グループ削除    
グループエピック削除    
通知メールの無効化    
グループ設定の編集    
SAML SSO の編集    ✓ (3)
2FAステータスによるメンバーのフィルタリング    
グループレベルのCI/CD変数の管理    
グループメンバーの管理    
グループとグループの共有(招待    
メンバーの2FAステータスの表示    
請求書を見る    ✓ (3)
グループの利用枠のページを見る    ✓ (3)
グループランナーの管理    
グループのマイグレーション    
サブスクリプションの管理、ストレージとコンピュート分の購入     
  1. グループは、オーナー、またはオーナーとメンテナーのロールを持つユーザーがサブグループを作成できるように設定できます。
  2. デフォルトのプロジェクト作成ロールは以下で変更できます:
  3. サブグループには適用されません。
  4. 開発者が新しいプロジェクトのデフォルトブランチにコミットをプッシュできるのは、デフォルトブランチの保護が“Partially protected” あるいは “Not protected” に設定されている場合だけです。
  5. さらに、グループが公開または内部の場合、グループを見ることができるすべてのユーザーはグループの Wiki ページも見ることができます。
  6. ユーザーは各自のアクションに基づくイベントのみを表示できます。
  7. エピックの閲覧およびイシューの編集には権限が必要です。
  8. 親エピックおよび子エピックを表示する権限が必要です。

サブグループの権限

サブグループにメンバーを追加すると、そのメンバーは親グループのメンバーシップと権限レベルを継承します。このモデルでは、親グループのいずれかのメンバーシップを持っている場合、ネストしたグループへのアクセスが許可されます。

詳細については、サブグループのメンバーシップを参照してください。

最小限のアクセスしかできないユーザー

  • GitLab 13.4 で導入されました
  • GitLab 15.9 で導入されたMinimal Access ロールを持つユーザーの招待をサポート。

Minimal Access ロールを持つユーザーは招待できません:

  • セルフマネージドUltimateサブスクリプションやGitLab.comサブスクリプションのライセンスシートとしてカウントされません。
  • ルートグループ内のプロジェクトやサブグループに自動的にアクセスできます。

オーナーは、これらのユーザーを特定のサブグループとプロジェクトに明示的に追加する必要があります。

Minimal Accessロールを使用して、同じメンバーにグループ内で複数のロールを与えることができます:

  1. 最小アクセス・ロールを持つルート・グループにメンバーを追加します。
  2. グループ内の任意のサブグループまたはプロジェクトに、特定のロールを持つ直接メンバとしてメンバを招待します。

未解決のイシューがあるため、Minimal Accessロールを持つユーザーを招待することはできません:

  • 標準のWeb認証でサインインすると、親グループへのアクセス時に404 エラーが発生します。
  • グループ SSO でサインインすると、親グループのページにリダイレクトされるため、404 エラーがすぐに発生します。

このイシューを回避するには、これらのユーザーに、親グループ内のプロジェクトまたはサブグループのゲスト以上のロールを与えます。

カスタム・ロール

カスタムロールにより、オーナーロールを割り当てられたグループメンバーは、組織のニーズに合わせたロールを作成することができます。

カスタムロール機能のデモについては、[Demo] Ultimate Guest can view code on private repositories via custom roleを参照してください。

以下のカスタムロールが利用できます:

  • Guest+1ロールは、Guestロールを持つユーザーにコードの閲覧を許可します。
  • GitLab 16.1以降では、脆弱性レポートを閲覧し、脆弱性のステータスを変更できるカスタムロールを作成できます。
  • GitLab 16.3以降では、依存性リストを閲覧できるカスタムロールを作成できます。
  • GitLab 16.4 以降では、マージリクエストを承認できるカスタムロールを作成できます。

個々のカスタムロールと権限リクエストについては、イシュー391760 を参照してください。

ゲスト・ロールを持つユーザに対して脆弱性カスタム・ロールを有効にすると、そのユーザは昇格された権限にアクセスできるようになります:

これはGuest+1カスタムロールには適用されません。なぜなら、view_code の能力はこの動作から除外されているからです。

カスタムロールの作成

グループのカスタムロールを有効にするには、オーナーロールを持つグループメンバーが必要です:

  1. Guestにカスタムロールを与えた効果を確認できるように、このグループまたはそのサブグループの1つに、少なくとも1つの非公開プロジェクトがあることを確認してください。
  2. APIスコープで個人アクセストークンを作成します。
  3. APIを使用してルートグループのカスタムロールを作成します。

カスタムロールの要件

すべての能力について、最小アクセスレベルが定義されています。特定の能力を有効にするカスタム・ロールを作成するには、member_roles テーブル・レコードが関連する最小アクセス・レベルを持っている必要があります。すべての能力について、最小アクセス・レベルはGuestです。少なくともGuestロールを持つユーザだけがカスタム・ロールに割り当てられます。

一部のロールおよび能力では、他の能力を有効にする必要があります。たとえば、カスタム・ロールが脆弱性の管理 (admin_vulnerability) を有効にできるのは、脆弱性の読み取り (read_vulnerability) も有効になっている場合のみです。

必要な最小アクセス・レベルと必要な能力は、以下の表で確認できます。

read_code |ゲスト|-|read_dependency |ゲスト|-|read_vulnerability |ゲスト|-|admin_merge_request |ゲスト|-|admin_vulnerability |ゲスト|read_vulnerability |。

既存のグループメンバーにカスタムロールを関連付けます。

カスタムロールを既存のグループメンバーに関連付けるには、オーナーロールを持つグループメンバーを指定します:

  1. ルートグループ、またはルートグループの階層内の任意のサブグループやプロジェクトに、直接のメンバーとしてユーザーをゲストとして招待します。この時点で、このゲストユーザーは、グループまたはサブグループ内のプロジェクトのコードを見ることはできません。
  2. オプション。オーナーがID カスタム・ロールを受け取るゲスト・ユーザーを ID知らない場合IDID APIリクエストを行うことでID それを見つけます ID

  3. Group and Project Members APIエンドポイントを使用して、メンバーをGuest+1ロールに関連付けます。

    # to update a project membership
    curl --request PUT --header "Content-Type: application/json" --header "Authorization: Bearer $YOUR_ACCESS_TOKEN" --data '{"member_role_id": '$MEMBER_ROLE_ID', "access_level": 10}' "https://example.gitlab.com/api/v4/projects/$ID/members/$GUEST_USER_ID"
       
    # to update a group membership
    curl --request PUT --header "Content-Type: application/json" --header "Authorization: Bearer $YOUR_ACCESS_TOKEN" --data '{"member_role_id": '$MEMBER_ROLE_ID', "access_level": 10}' "https://example.gitlab.com/api/v4/groups/$ID/members/$GUEST_USER_ID"
    

    どこに:

    これで、Guest+1ユーザーは、このメンバーシップに関連付けられたすべてのプロジェクトのコードを閲覧できるようになります。

グループメンバーからのカスタムロールの削除

グループ・メンバーからカスタム・ロールを削除するには、Group and Project Members APIエンドポイントを使用し、空のmember_role_id 値を渡します。

curl --request PUT --header "Content-Type: application/json" --header "Authorization: Bearer $YOUR_ACCESS_TOKEN" --data '{"member_role_id": "", "access_level": 10}' "https://example.gitlab.com/api/v4/groups/$GROUP_PATH/members/$GUEST_USER_ID"

これでユーザーは通常のゲストとなります。

カスタムロールの削除

カスタムロールを削除すると、そのカスタムロールを持つすべてのメンバーもグループから削除されます。カスタムロールを削除する場合は、そのカスタムロールを持つユーザをグループに追加し直す必要があります。

グループからカスタムロールを削除するには、オーナーロールを持つグループメンバーをグループから削除します:

  1. オプション。オーナーがID カスタムロールを ID知らない場合は、APIリクエストで確認してください。
  2. APIを使用してカスタムロールを削除します。

既知のイシュー

  • 追加権限は、ゲストロールを持つユーザーにのみ適用できます。
  • カスタムロールを持つユーザーがグループやプロジェクトと共有された場合、そのカスタムロールは引き継がれません。ユーザーは新しいグループまたはプロジェクトで通常のGuestロールを持ちます。
  • 監査役ユーザをカスタムロールのテンプレートとして使用することはできません。