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

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

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

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

• 直接転送を使用する場合のGitLab
• GitHub
• Bitbucket Server
• Gitea

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

前提条件

• ユーザー制限に基づいてユーザー数を計画してください。
• GitLab.comにインポートする場合は、有料ネームスペースを設定してください。
• GitLab.comにインポートし、かつGitLab.comグループにSAML SSOを使用する場合は、すべてのユーザーがSAMLアイデンティティをGitLab.comアカウントにリンクしていることを確認してください。

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

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

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

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

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

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

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

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

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

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

削除されたユーザー

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

• そのコントリビュートが、移行元インスタンスで削除されたユーザーから適切に切り離されていなかった場合。
• 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に割り当てられている場合、最初の承認のみが作成され、その他は無視されます。重複排除される可能性のあるコントリビュートは次のとおりです。

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

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

代替のマッピング方法

移行後マッピングの代替手段として、移行中にマッピングする方法があります。この方法は推奨されておらず、見つかった問題が修正される可能性は低いです。

代替のマッピング方法:

• GitLab Self-Managedへの移行でのみ利用可能です。
• 移行前にいくつかの準備が必要です。これには、適用される*_user_mapping機能フラグの無効化が含まれます。
• 次の環境からの移行に利用できます:
  • GitHub。
  • Bitbucket Server。
  • Gitea（GitLab 18.5以前）。

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