要約

This article addresses a confusing behavior that may arise when resolving duplicated email addresses. This issue only occurs when changing the options to fix duplicates during migrations.

概要

The Jira Cloud Migration Assistant includes a step to Assess and prepare your users that lets you assess your server users to find invalid and duplicated email addresses that block the migration. After the assessment, you can choose one of the options to automatically fix the problems with such email addresses during migration. Learn more about assessing and preparing users

This article explains a potential behavior that arises when addressing duplicated email addresses. This behavior is specific to situations where changes are made to fix duplicate emails between migrations.

例:

1. Initially, you choose the option to Create new emails for duplicated users and migrate some projects with users.
2. Then you change to the option Merge duplicated users and migrate other projects with users from the same instance.

This approach is not advisable. It's best to select one option for dealing with duplicated users and maintain it throughout the entire migration process. If a change in option becomes necessary, it can be made; however, keep in mind that doing so will result in the behavior outlined in this article.

シナリオ

このシナリオの例として、重複したメール アドレスを持つ次のサーバー ユーザーについて考えます。

• user1 (user@atlassian.com)

• user2 (user@atlassian.com)

• user3 (user@atlassian.com)

アクション 1

最初は、これらのユーザーを個々のユーザーとして移行して、個別のアクティビティとアイデンティティを維持したいと考えていました。移行アシスタントで、[新しいメール アドレスを重複するユーザーに作成] オプションを選択して、一部のプロジェクトを移行しました。

結果

On Cloud, you ended up with 3 users, each with a new email address generated based on UserID:

• useri_10501@atlassian.com (user1)

• useri_10502@atlassian.com (user2)

• useri_10503@atlassian.com (user3)

これは想定どおりの挙動です。このオプションを使用してすべてのプロジェクトを移行した場合、問題はないはずです。

アクション 2

Since all these users were migrated into a group that has product access, all of them were consuming licenses. To save license costs or just reduce the number of users in Cloud, you decided to merge these duplicates instead.

移行アシスタントで、[重複するユーザーをマージ] を選択し、同じインスタンスから他のプロジェクトを移行しました (同じプロジェクトを再び移行することはできませんでした)。

結果

シナリオの説明に記載されている元のサーバー ユーザーは、1 つのアカウントにマージされました。

• user@atlassian.com (メイン アカウント: user1、user2 および user3 のコンテンツを含む)

このような場合、常に 1 つのアカウントが (ランダムに) メイン アカウントとして選択され、残りのアカウントのコンテンツがメイン アカウントにマージされます。

前に移行したユーザーも Cloud に残りました。これらのユーザーが上書きされなかったのは、Cloud に個別のユーザーとして存在し、それぞれが独自のメール アドレスを持っているためです。

• useri_10501@atlassian.com (user1)

• useri_10502@atlassian.com (user2)

• useri_10503@atlassian.com (user3)

問題

問題 1: 重複アカウント

現在、Cloud の user1 は「重複」しています。

• マージ アカウント: user@atlassian.com (メイン アカウント: user1、user2 および user3 のコンテンツを含む)

• 新しいメール アカウント: useri_10501@atlassian.com (user1)

• You could also consider the new email accounts for user2 and user3 duplicated accounts (because their content is already included in the merged account). But, since these accounts weren’t used as the main ones when creating the merged account, they don’t affect the references in a confusing way.

これらは現状も個別のメールを持つ個々のユーザーですが、直近で [重複するユーザーをマージ] アクションを実行したため、前に移行したアカウントはマージ アカウントで上書きされると予想していたかと思われます。実際にはそうではありません。前に移行したものは Cloud サイトに残ります。

問題 2: 参照

さらに紛らわしい問題は、移行したすべてのプロジェクトでこれらの重複アカウントの参照先 (たとえば、メンション) が次のように異なることです。

• user2 および user3 の参照先はマージ アカウント user@atlassian.com (メイン アカウント: user1、user2 および user3 のコンテンツを含む) になります。

• user1 の参照先は新しいメール アカウント useri_10501@atlassian.com (user1) になります。

直近でアカウントのマージ アクションを実行したため、すべての参照がマージ アカウントに対して行われると予想していたかと思われます。それは、user2 および user3 についてのみ当てはまります。

推奨事項

この問題には適切なソリューションがありません。したがって、1 つのオプションを選択したら、同じインスタンスのすべての移行作業が完了するまでオプションを変更しないことをお勧めします。Cloud で冗長なユーザーを削除しても役に立ちません。ユーザーは削除され (旧ユーザーになる)、余分なライセンスは消費されなくなりますが、移行済みのプロジェクトにおける参照は「旧ユーザー」に対して行われるか、「旧ユーザー」として表示されます。新たに移行されたユーザーに再マッピングされることはありません。