移行後のコントリビュートおよびメンバーシップのマッピング

移行後のマッピングにより、ソースインスタンスからのユーザーコントリビュートとメンバーシップは、宛先インスタンス上の実際のユーザーではなく、最初にプレースホルダユーザーに割り当てられます。

実際のユーザーへの割り当てを延期できるため、インポートをレビューし、正しいユーザーにコントリビュートを再割り当てする時間を確保できます。このプロセスにより、マッピングプロセスを制御しながら、正確な属性を保証できます。

移行後のユーザーコントリビュートとメンバーシップのマッピングは、次からの移行でデフォルトで利用できます:

• ダイレクトトランスファーを使用する場合のGitLab
• GitHub
• Bitbucket Server
• Gitea

プロジェクトをパーソナルネームスペースにインポートする場合、ユーザーコントリビュートマッピングとメンバーシップマッピングはサポートされず、すべてのコントリビュートはパーソナルネームスペースオーナーに割り当てられます。これらのコントリビュートは再割り当てできません。

前提条件

• ユーザー制限に従って、ユーザー数を計画します。
• GitLab.comにインポートする場合は、有料ネームスペースを設定します。
• GitLab.comにインポートし、GitLab.comグループのSAML SSOを使用する場合は、すべてのユーザーがSAML IDをGitLab.comアカウントにリンクしていることを確認します。

移行後のマッピングワークフロー

移行後のマッピングを使用する場合、GitLabはインポートするすべてのメンバーシップとコントリビュートをプレースホルダユーザーにマップします。プレースホルダユーザーは、ソースインスタンスに同じメールアドレスを持つユーザーが存在する場合でも、宛先インスタンスに作成されます。宛先インスタンスでコントリビュートを再割り当てするまで、すべてのコントリビュートはプレースホルダユーザーに関連付けられます。

インポートが完了し、結果をレビューしたら、次のようにマッピングを更新できます:

• 宛先インスタンス上の既存のユーザーにメンバーシップとコントリビュートを再割り当てします。移行元インスタンスと移行先インスタンスで異なるメールアドレスを持つユーザーのメンバーシップとコントリビュートをマッピングできます。
• 宛先インスタンスに新しいユーザーを作成し、それらにメンバーシップとコントリビュートを再割り当てします。

特定のコントリビュートをプレースホルダユーザーに割り当てたままにして、履歴コンテキストを保持することもできます。

宛先インスタンス上のユーザーにコントリビュートを再割り当てすると、ユーザーは次のいずれかを選択できます:

• 再割り当てを受け入れる。再割り当てプロセスには数分かかる場合があります。その後、同じソースインスタンスから、宛先インスタンス上の同じトップレベルグループまたはサブグループにインポートすると、コントリビュートはユーザーに自動的にマッピングされます。
• 再割り当てを拒否する。

エンタープライズユーザー

トップレベルグループに少なくとも1人のエンタープライズユーザーがいる場合、組織内のエンタープライズユーザーにのみコントリビュートを再割り当てすることができます。

つまり、組織外のユーザーに誤って再割り当てしてしまうことはありません。

削除されたユーザー

ソースインスタンスで、現在削除されているユーザーによって行われたコントリビュートは、次の場合を除き、宛先インスタンス上のGhostユーザーにマップされます:

• コントリビュートがソースインスタンス上の削除されたユーザーから適切に切り離されなかった。
• Bitbucket Serverから移行する場合。

プレースホルダーユーザー

コントリビュートとメンバーシップのマッピングでは、コントリビュートとメンバーシップを宛先インスタンス上のユーザーにすぐに割り当てることはありません。代わりに、インポートされたコントリビュートまたはメンバーシップを持つアクティブ、非アクティブ、またはボットユーザーに対してプレースホルダユーザーが作成されます。

コントリビュートとメンバーシップはどちらも、最初にこれらのプレースホルダユーザーに割り当てられ、インポート後に宛先インスタンス上の既存のユーザーに再割り当てすることができます。

再割り当てられるまで、コントリビュートはプレースホルダーに関連付けられています。プレースホルダーのメンバーシップは、メンバーリストには表示されません。

プレースホルダーユーザーは、ライセンス制限にはカウントされません。

例外

プレースホルダユーザーは、次のシナリオでは作成されません:

• 削除されたユーザーからのコントリビュートがあるGiteaからプロジェクトをインポートしています。これらのユーザーからのコントリビュートは、プロジェクトをインポートしたユーザーにマップされます。
• プレースホルダーユーザー制限を超過しました。新しいユーザーからのコントリビュートは、インポートユーザーにマップされます。

プレースホルダーユーザー属性

プレースホルダーユーザーは通常のユーザーとは異なり、次のことはできません。

• サインイン。
• アクションを実行する。たとえば、パイプラインの実行などです。
• イシューおよびマージリクエストの担当者またはレビュアーとして候補に表示されます。
• プロジェクトおよびグループのメンバーになる。

ソースインスタンス上のユーザーとの接続を維持するために、プレースホルダーユーザーには次のものがあります。

• 新しいプレースホルダーユーザーが必要かどうかをインポートプロセスが判断するために使用する固有識別子（source_user_id）。
• ソースホスト名またはドメイン（source_hostname）。
• コントリビュートの再割り当てを支援するためのソースユーザーの名前（source_name）。
• コントリビュートの再アサイン中にグループオーナーを支援するためのソースユーザーのユーザー名（source_username）。
• どのインポーターがプレースホルダーを作成したかを区別するインポートタイプ（import_type）。
• 移行追跡のために移行元ユーザーが作成されたときのタイムスタンプ（created_at）（ローカル時刻）（GitLab 17.10で導入）。

履歴コンテキストを保持するために、プレースホルダーユーザー名とユーザー名は、移行元ユーザー名とユーザー名から派生します。

• プレースホルダーユーザーの名前はPlaceholder <source user name>です。
• プレースホルダーユーザーのユーザー名は%{source_username}_placeholder_user_%{incremental_number}です。

プレースホルダーユーザーを表示する

前提条件:

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

トップレベルグループとそのサブグループへのインポート中に、プレースホルダーユーザーが移行先インスタンスに作成されます。トップレベルグループとそのサブグループへのインポート中に作成されたプレースホルダーユーザーを表示するには:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
2. 管理 > メンバーを選択します。
3. プレースホルダータブを選択します。

プレースホルダーユーザーをフィルタリングする

前提条件:

• インスタンスへの管理者アクセス権が必要です。

トップレベルグループとそのサブグループへのインポート中に、プレースホルダーユーザーが移行先インスタンスに作成されます。インスタンス全体のインポート中に作成されたプレースホルダーユーザーをフィルタリングするには:

1. 右上隅で、管理者を選択します。
2. 概要 > ユーザーを選択します。
3. 検索ボックスで、タイプでユーザーをフィルタリングします。

プレースホルダーユーザーを作成する

プレースホルダユーザーは、インポート元ごと、およびトップレベルグループごとに作成されます:

• 同じプロジェクトを移行先インスタンスの同じトップレベルグループに2回インポートする場合、2回目のインポートでは最初のインポートと同じプレースホルダーユーザーが使用されます。
• 同じプロジェクトを2回インポートしても、移行先インスタンスの異なるトップレベルグループにインポートする場合、2回目のインポートではそのトップレベルグループの下に新しいプレースホルダーユーザーが作成されます。

ユーザーが再アサインを承認すると、同じソースインスタンスから、宛先インスタンス上の同じトップレベルグループまたはサブグループにインポートしても、プレースホルダーユーザーは作成されません。代わりに、コントリビュートはユーザーに自動的にマッピングされます。

プレースホルダーユーザーの削除

プレースホルダユーザーを含むトップレベルグループを削除すると、これらのユーザーは自動的に削除のスケジュールが設定されます。このプロセスが完了するまでに時間がかかる場合があります。ただし、プレースホルダユーザーが他のプロジェクトまたはグループにも関連付けられている場合、システムに残ります。

プレースホルダーユーザー制限

GitLab.comにインポートする場合、プレースホルダーユーザーは、移行先インスタンスのトップレベルグループごとに制限されます。制限は、プランとシート数によって異なります。プレースホルダーユーザーは、ライセンス制限にはカウントされません。

GitLab Self-ManagedおよびGitLab Dedicatedの場合、デフォルトではプレースホルダー制限は適用されません。GitLab管理者は、インスタンスのプレースホルダー制限を設定できます。

現在のプレースホルダーユーザーの使用量と制限を表示するには:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
2. 設定 > 使用量クォータを選択します。
3. インポートタブを選択します。

事前に必要なプレースホルダーユーザーの数を判断することはできません。

プレースホルダーユーザー制限に達すると、すべてのコントリビュートがImport Userという単一の非機能ユーザーに割り当てられます。Import Userに割り当てられたコントリビュートは重複排除される可能性があり、インポート中に一部のコントリビュートが作成されない可能性があります。たとえば、マージリクエストの承認者からの複数の承認がImport Userに割り当てられている場合、最初の承認のみが作成され、その他は無視されます。重複排除される可能性のあるコントリビュートは次のとおりです。

• 承認ルール
• 絵文字リアクション
• イシューの担当者
• メンバーシップ
• マージリクエストの承認、担当者、レビュアー
• プッシュ、マージリクエスト、およびデプロイのアクセスレベル

すべての変更によってシステムノートが作成されます。これは、プレースホルダーユーザー制限の影響を受けません。

コントリビュートとメンバーシップの再アサイン

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

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

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

プレースホルダユーザーを再割り当てするときの確認をバイパスする

前提条件:

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

プレースホルダーを再割り当てするときに、エンタープライズユーザーの確認をバイパスするには:

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

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

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

プレースホルダーユーザーが以下からのユーザーである場合、複数のプレースホルダーユーザーからのコントリビュートを宛先インスタンス上の同じユーザーに再アサインできます。

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

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

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

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

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

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

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

再アサインの完了

再アサインプロセスは、次の操作を行う前に完全に完了する必要があります:

• 同じGitLabインスタンス内でインポートされたグループを移動する。
• インポートされたプロジェクトを別のグループに移動する。
• インポートされたイシューを複製します。
• インポートされたイシューをエピックにプロモートします。

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

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

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

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

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

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

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

インポートされたグループまたはプロジェクトの既存の継承されたメンバーシップをすでに持っているユーザーをコントリビュートとメンバーシップの再アサインに選択すると、メンバーシップがそのユーザーにどのように再アサインされるかに影響を与える可能性があります。

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

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

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

前提条件:

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

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

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

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

ユーザーが再アサインを承認する前に、リクエストをキャンセルできます。

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

CSVファイルを使用して再アサインをリクエストする

前提条件:

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

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

ソースホスト、インポートタイプ、またはソースユーザー識別子を更新しないでください。この情報は、完成した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. リストの上にある縦方向の省略記号（ ）> すべてをプレースホルダーとして保持を選択します。
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で再アサインを承認を選択して再アサインリクエストを承認した後にのみ開始されます。プロセスは、メール内のリンクを選択しても開始されません。

代替マッピング方法

移行後のマッピングの代替手段は、移行中にマップする方法です。この方法はお勧めしません。見つかった問題が修正される可能性は低いです。

代替のマッピング方法:

• 移行前に、機能フラグを無効にするなど、いくつかの準備が必要です。
• 次のものからの移行に利用できます:
  • GitHub。
  • Bitbucket Server。
  • Gitea（GitLab 18.5以前）。
• GitLab Self-ManagedおよびGitLab Dedicatedへの移行に利用できます。

詳細については、各インポーターのマッピングドキュメントの代替方法を参照してください。