正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

コントリビュートとメンバーシップの再割り当て

トップレベルグループのオーナーロールを持つユーザーは、プレースホルダーユーザーから既存のアクティブな非ボットユーザーにコントリビュートとメンバーシップを再割り当てできます。移行先インスタンスでは、トップレベルグループのオーナーロールを持つユーザーは、次のことができます:

  • UIで、またはCSVファイルを介して、ユーザーにコントリビュートとメンバーシップの再割り当てをレビューするようリクエストします。多数のプレースホルダーユーザーがいる場合は、CSVファイルを使用する必要があります。どちらの場合も、ユーザーは再割り当てを受け入れるか拒否するためのリクエストをメールで受信します。選択したユーザーが再割り当てリクエストを承認した後にのみ、再割り当てが開始されます。
  • コントリビュートとメンバーシップを再割り当てしないことを選択し、プレースホルダーユーザーに割り当てられたままにします。

GitLab Self-ManagedおよびGitLab Dedicatedでは、管理者はユーザーの確認なしに、コントリビュートとメンバーシップをアクティブおよび非アクティブの非ボットユーザーにすぐに再割り当てできます。詳細については、管理者がプレースホルダーユーザーを再割り当てする際に確認をスキップするを参照してください。コントリビュートとメンバーシップを管理者に再割り当てするには、コントリビュートを管理者にマッピングできるようにするを参照してください。

プレースホルダーユーザーを再割り当てする際の確認を回避する

  • プラン: Premium、Ultimate
  • 提供形態: GitLab.com

前提条件:

  • グループのオーナーのロールを持っている必要があります。

プレースホルダーを再割り当てする際にエンタープライズユーザーの確認を回避するには:

  1. 上部のバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
  2. 設定 > 一般を選択します。
  3. 権限とグループ機能を展開します。
  4. プレースホルダーユーザーの確認で、プレースホルダーをユーザー認証なしにエンタープライズユーザーに再割り当てチェックボックスを選択します。
  5. ユーザーの確認の復元するタイミングで、ユーザーの確認回避の終了日を選択します。デフォルト値は1日です。
  6. 変更を保存を選択します。

複数のプレースホルダーユーザーからのコントリビュートを再割り当てする

最初に単一のプレースホルダーユーザーに割り当てられたすべてのコントリビュートを、移行先インスタンス上の単一のアクティブな標準ユーザー、サービスアカウント、プロジェクトボット、グループボットに再割り当てできます。単一のプレースホルダーユーザーに割り当てられたコントリビュートを複数のユーザーに分割することはできません。

プレースホルダーユーザーが以下からのユーザーである場合、複数のプレースホルダーユーザーからのコントリビュートを移行先インスタンス上の同じユーザーに再割り当てできます:

  • 異なる移行元インスタンス
  • 同じ移行元インスタンス（移行先インスタンス上の異なるトップレベルグループにインポートされる）

割り当てられたユーザーが再割り当てリクエストを承認する前に無効になった場合、保留中の再割り当ては、ユーザーが承認するまでユーザーにリンクされたままになります。

再割り当てリクエストを受信するユーザーは、次のことができます:

  • リクエストを承認する。以前にプレースホルダーユーザーに起因していたすべてのコントリビュートとメンバーシップは、承認ユーザーに再割り当てされます。このプロセスには、コントリビュートの数に応じて数分かかる場合があります。
  • リクエストを拒否するか、スパムとして報告します。このオプションは、再割り当てリクエストメールで利用できます。

サービスアカウント、プロジェクトボット、グループボットにコントリビュートを再割り当てすると、再割り当てリクエストが自動的に承認されます。

それ以降、同じトップレベルグループへのインポートでは、同じ移行元ユーザーに属するコントリビュートとメンバーシップは、その移行元ユーザーの再割り当てを以前に承認したユーザーに自動的にマッピングされます。

GitLab Self-ManagedおよびGitLab Dedicatedでは、管理者はユーザーの確認なしに、コントリビュートとメンバーシップをアクティブおよび非アクティブの非ボットユーザーにすぐに再割り当てできます。詳細については、管理者がプレースホルダーユーザーを再割り当てする際に確認をスキップするを参照してください。コントリビュートとメンバーシップを管理者に再割り当てするには、コントリビュートを管理者にマッピングできるようにするを参照してください。

再割り当てを完了する

再割り当てプロセスは、次の操作を行う前にすべて完了する必要があります:

プロセスが完了していない場合、プレースホルダーユーザーに割り当てられたままのコントリビュートは、実際のユーザーに再割り当てできず、プレースホルダーユーザーに関連付けられたままになります。

セキュリティに関する考慮事項

コントリビュートとメンバーシップの再割り当ては元に戻すことができないため、開始する前にすべてを注意深く確認してください。

コントリビュートとメンバーシップを誤ったユーザーに再割り当てすると、そのユーザーがグループのメンバーになるため、セキュリティ上の脅威となります。そのため、閲覧を許可されていない情報を閲覧できるようになります。

管理者アクセス権を持つユーザーへのコントリビュートの再割り当てはデフォルトで無効になっていますが、有効にすることができます。

メンバーシップのセキュリティに関する考慮事項

GitLabの権限モデルにより、グループまたはプロジェクトが既存の親グループにインポートされると、親グループのメンバーには、インポートされたグループまたはプロジェクトの継承されたメンバーシップが付与されます。

インポートしたグループまたはプロジェクトの既存の継承されたメンバーシップをすでに持っているユーザーを、コントリビュートとメンバーシップの再割り当て先として選択すると、そのユーザーへのメンバーシップの再割り当て方法に影響が出る可能性があります。

GitLabでは、子プロジェクトまたはグループのメンバーシップが、継承されたメンバーシップよりも低いロールを持つことは許可されていません。割り当てられたユーザーのインポートされたメンバーシップが、既存の継承されたメンバーシップよりも低いロールを持っている場合、インポートされたメンバーシップはユーザーに再割り当てされません。

その結果、インポートされたグループまたはプロジェクトのメンバーシップが、移行元よりも高い状態になります。

UIで再割り当てをリクエストする

前提条件:

  • グループのオーナーのロールを持っている必要があります。

トップレベルグループでコントリビュートとメンバーシップを再割り当てできます。コントリビュートとメンバーシップの再割り当てをリクエストするには:

  1. 上部のバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
  2. 管理 > メンバーを選択します。
  3. プレースホルダータブを選択します。
  4. 再割り当て待ちサブタブに移動します。プレースホルダーがテーブルにリストされています。
  5. 各プレースホルダーについて、テーブルの列プレースホルダーユーザーとソースの情報をレビューします。
  6. プレースホルダーの再割り当て先列で、ドロップダウンリストからユーザーを選択します。
  7. 再割り当てを選択します。

1つのプレースホルダーユーザーのコントリビュートのみを、移行先インスタンスのアクティブな非ボットユーザーに再割り当てできます。

ユーザーが再割り当てを承認する前に、リクエストをキャンセルできます。

GitLab Self-ManagedおよびGitLab Dedicatedでは、管理者はユーザーの確認なしに、コントリビュートとメンバーシップをアクティブおよび非アクティブの非ボットユーザーにすぐに再割り当てできます。詳細については、管理者がプレースホルダーユーザーを再割り当てする際に確認をスキップするを参照してください。コントリビュートとメンバーシップを管理者に再割り当てするには、コントリビュートを管理者にマッピングできるようにするを参照してください。

CSVファイルを使用して再割り当てをリクエストする

前提条件:

  • グループのオーナーのロールを持っている必要があります。

多数のプレースホルダーユーザーが存在する場合、CSVファイルを使用してコントリビュートとメンバーシップを再割り当てできます。次の情報を含む、事前入力されたCSVテンプレートをダウンロードできます。例:

ソースホストインポートタイプソースユーザー識別子ソースユーザーの氏名ソースユーザー名
gitlab.example.comgitlabaliceAlice Codera.coder

ソースホスト、インポートタイプ、またはソースユーザー識別子を更新しないでください。この情報は、完成したCSVファイルをアップロードした後で、対応するデータベースレコードを見つけるために使用されます。ソースユーザーの氏名とソースユーザー名は、ソースユーザーを識別するものであり、CSVファイルをアップロードした後は使用されません。

CSVファイルのすべての行を更新する必要はありません。GitLabユーザー名またはGitLabパブリックメールを含む行のみが処理されます。他のすべての行はスキップされます。

CSVファイルを使用してコントリビュートとメンバーシップの再割り当てをリクエストするには:

  1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
  2. 管理 > メンバーを選択します。
  3. プレースホルダータブを選択します。
  4. CSVで再割り当てを選択します。
  5. 事前入力されたCSVテンプレートをダウンロードします。
  6. GitLabユーザー名またはGitLabパブリックメールに、移行先インスタンスのGitLabユーザーのユーザー名またはパブリックメールアドレスを入力します。インスタンス管理者は、確認済みのメールアドレスを持つユーザーを再割り当てできます。
  7. 完成したCSVファイルをアップロードします。
  8. 再割り当てを選択します。

単一のプレースホルダーユーザーからのコントリビュートのみを、移行先インスタンスの各アクティブな非ボットユーザーに割り当てることができます。ユーザーは、自分に再割り当てされたコントリビュートをレビューして承認するためのメールを受信します。ユーザーがレビューする前に、再割り当てリクエストをキャンセルできます。

GitLab Self-ManagedおよびGitLab Dedicatedでは、管理者はユーザーの確認なしに、コントリビュートとメンバーシップをアクティブおよび非アクティブの非ボットユーザーにすぐに再割り当てできます。詳細については、管理者がプレースホルダーユーザーを再割り当てする際に確認をスキップするを参照してください。コントリビュートとメンバーシップを管理者に再割り当てするには、コントリビュートを管理者にマッピングできるようにするを参照してください。

コントリビュートを再割り当てすると、GitLabから次の数が記載されたメールが送信されます:

  • 正常に処理された行
  • 正常に処理されなかった行
  • スキップされた行

正常に処理されなかった行がある場合、メールには、より詳細な結果が記載されたCSVファイルが添付されます。

UIを使用せずにプレースホルダーユーザーを一括で再割り当てするには、グループプレースホルダー再割り当てAPIを参照してください。

プレースホルダーとして保持する

コントリビュートとメンバーシップを移行先インスタンスのユーザーに再割り当てしたくない場合があります。たとえば、移行元インスタンスでコントリビュートした元従業員がいて、移行先インスタンスにユーザーとして存在しない場合があります。

このような場合は、コントリビュートをプレースホルダーユーザーに割り当てたままにすることができます。プレースホルダーユーザーは、プロジェクトまたはグループのメンバーになることができないため、メンバーシップ情報を保持しません。

プレースホルダーユーザーの名前とユーザー名は、移行元ユーザーの名前とユーザー名に似ているため、多くの履歴コンテキストを保持できます。

コントリビュートをプレースホルダーユーザーに割り当てたままにすることは、一度に1つずつ行うか、一括で行うことができます。コントリビュートを一括で再割り当てすると、ネームスペース全体と、次の再割り当てステータスを持つユーザーが影響を受けます。

  • Not started
  • Rejected

プレースホルダーユーザーを一度に1つずつ保持するには:

  1. 上部のバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
  2. 管理 > メンバーを選択します。
  3. プレースホルダータブを選択します。
  4. 再割り当て待ちサブタブに移動します。プレースホルダーがテーブルにリストされています。
  5. プレースホルダーユーザーおよびソース列をレビューして、保持するプレースホルダーユーザーを見つけます。
  6. 再割り当て先のプレースホルダー列で、再割り当てしないを選択します。
  7. 確認を選択します。

プレースホルダーユーザーを一括で保持するには:

  1. 上部のバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
  2. 管理 > メンバーを選択します。
  3. プレースホルダータブを選択します。
  4. リストの上にある縦方向の省略記号（ ellipsis_v ）> すべてをプレースホルダーとして保持を選択します。
  5. 確認ダイアログで、確認を選択します。

操作を取り消すには:

  1. 上部のバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
  2. 管理 > メンバーを選択します。
  3. プレースホルダータブを選択します。
  4. 再割り当て済サブタブに移動します。プレースホルダーがテーブルにリストされています。
  5. 該当する行で元に戻すを選択します。

再割り当てリクエストをキャンセルする

ユーザーが再割り当てリクエストを承認する前に、リクエストをキャンセルできます:

  1. 上部のバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
  2. 管理 > メンバーを選択します。
  3. プレースホルダータブを選択します。
  4. 再割り当て待ちサブタブに移動します。プレースホルダーがテーブルにリストされています。
  5. 正しい行でキャンセルを選択します。

保留中の再割り当てリクエストについて、再度ユーザーに通知する

ユーザーが再割り当てリクエストに対応していない場合は、別のメールを送信して再度プロンプトを表示できます。

  1. 上部のバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
  2. 管理 > メンバーを選択します。
  3. プレースホルダータブを選択します。
  4. 再割り当て待ちサブタブに移動します。プレースホルダーがテーブルにリストされています。
  5. 正しい行で通知を選択します。

再割り当てステータスで表示およびフィルタリングする

すべてのプレースホルダーユーザーの再割り当て状態を表示するには:

  1. 上部のバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
  2. 管理 > メンバーを選択します。
  3. プレースホルダータブを選択します。
  4. 再割り当て待ちサブタブに移動します。プレースホルダーがテーブルにリストされています。
  5. 再割り当てのステータス列で、各プレースホルダーユーザーの状態を確認します。

再割り当て待ちタブで使用可能なステータスは次のとおりです。

  • Not started - 再割り当ては開始されていません。
  • Pending approval - 再割り当ては、ユーザーの承認を待機しています。
  • Reassigning - 再割り当てが進行中です。
  • Rejected - 再割り当てはユーザーによって拒否されました。
  • Failed - 再割り当てに失敗しました。

再割り当て済タブで使用可能なステータスは次のとおりです。

  • Success - 再割り当てに成功しました。
  • Kept as placeholder - プレースホルダーユーザーが永続化されました。

デフォルトでは、テーブルはプレースホルダーユーザー名でアルファベット順に並べ替えられています。再割り当て状態でテーブルを並べ替えることもできます。

コントリビュートの再割り当てを確認する

管理者がプレースホルダーユーザーを再割り当てするときに承認をスキップするが有効になっている場合:

  • 管理者はユーザーの確認なしに、コントリビュートをすぐに再割り当てできます。
  • 管理者はコントリビュートをアクティブおよび非アクティブの非ボットユーザーに再割り当てできます。
  • コントリビュートが再割り当てされたことを通知するメールが届きます。

この設定が有効になっていない場合、再割り当てを承認または却下できます。

コントリビュートの再割り当てを承認する

インポート処理が行われたことを知らせるメールが届き、コントリビュートを自分自身に再割り当てすることを確認するように求められる場合があります。

このインポート処理について説明を受けていた場合でも、再割り当ての詳細を十分に注意して確認する必要があります。メールに記載されている詳細は次のとおりです。

  • インポート元 - インポートされたコンテンツの送信元プラットフォーム。たとえば、GitLab、GitHub、またはBitbucketの別のインスタンス。
  • 元のユーザー - ソースプラットフォーム上のユーザーの氏名とユーザー名。これは、そのプラットフォームでのあなたの氏名とユーザー名である可能性があります。
  • インポート先 - 新しいプラットフォームの名前。GitLabインスタンスのみです。
  • 再割り当て先 - GitLabインスタンスでのあなたの氏名とユーザー名。
  • 再割り当て者 - インポートを実行した同僚または上司の氏名とユーザー名。

コントリビュートの再割り当てを拒否する

コントリビュートの自分自身への再割り当てを確認するよう求めるメールを受信し、その内容に心当たりがない、または誤りがあることに気付いた場合は、次のようにします:

  1. 一切手続きを進めないか、コントリビュートの再割り当てを拒否してください。
  2. 信頼できる同僚または上司に相談してください。

セキュリティに関する考慮事項

再割り当てリクエストの再割り当ての詳細を十分に注意して確認する必要があります。信頼できる同僚または上司からこのプロセスについて事前に知らされていない場合は、特に注意してください。

疑わしい再割り当てを承認するのではなく、次のようにします:

  1. メールに対応しないでください。
  2. 信頼できる同僚または上司に相談してください。

面識があり信頼できるユーザーからの再割り当てのみを承認してください。コントリビュートの再割り当ては永続的であり、元に戻すことはできません。再割り当てを承認すると、コントリビュートが誤ってあなたに起因する可能性があります。

コントリビュートの再割り当てプロセスは、GitLabで再割り当てを承認するを選択して再割り当てリクエストを承認した後にのみ開始されます。プロセスは、メール内のリンクを選択しても開始されません。