Jira の課題やプロジェクトの過去のキーの移行
要約
Check how the logic between historical keys for issues and projects works on Jira Cloud when migrating.
概要
When you move an issue to a different project or rename a project, the issue keys change.
However, Jira reserves all previous historical keys so that it will still work if you try to access your issue using the link (pointing to its historical key).
These historical key reservations were not migrated until the Jira Cloud Migration Assistant (JCMA) 1.4.3.
Now that both your server and cloud sites may have clashing historical issue keys, we had to take measures during migration to resolve those conflicts, and you should know how we are doing this.
問題点
Let's assume ALPHA -1 is an issue belonging to project ALPHA in the cloud instance. It was later moved to another project, BETA, and its new key is BETA-5.
Before moving the issue, you may have saved the link somewhere; for example, you may have bookmarked it in the browser.
After it became BETA-5, the old link pointing to ALPHA-1 continues to work because it redirects your browser to BETA-5.
Now, let's say the ALPHA project no longer exists in the cloud, and you are migrating an entirely different, unrelated project, ALPHA, from your server instance, which also happens to have an issue with the key ALPHA-1.
Since your cloud instance can only return one result when searching for issue ALPHA-1, we have a choice to make.
In this case, we would resolve the conflict in favor of the server's version of ALPHA-1 because it is an issue's current/active key, which takes priority over a historical alias.
This would lead to a side effect where your bookmark to ALPHA-1 will now point to a different issue, ALPHA-1, which was migrated from the server and will no longer redirect to BETA-1.
On the other hand, if you had ALPHA-1 bookmarked, say on a page of your Confluence server instance, which was also migrated over to the cloud, the same conflict resolution logic would result in a desired behavior, where ALPHA-1 will still point to the correct issue after migration.
These are just two possible scenarios requiring conflict resolution, so you must understand how we resolve these clashes.
競合の解決ロジック
簡単に説明すると、解決ロジックは次の 2 つのシンプルなルールに従います。
現在の (アクティブな) キーが過去のものよりも優先される
Clashes between two historical keys are resolved in favor of the cloud version
As before, we don't allow clashes between two current keys for projects or issues.
Here's a detailed breakdown of possible clash scenarios and how we will resolve those:
プロジェクト
| サーバーでのキー | クラウドでの状態 | 優先対象 | 詳細 |
|---|---|---|---|
| アクティブ | 存在しない | N/A | There are no clashes, and the project gets migrated. |
| アクティブ | アクティブまたは履歴として存在 | N/A | Migration is not allowed, and pre-flight checks block it. |
| 履歴として存在 | 存在しない | N/A | There are no clashes; the historical key gets migrated and will become a historical key for its active project in the cloud. |
| 履歴として存在 | アクティブまたは履歴として存在 | クラウド | The server's historical key will be effectively ignored. After migration, this project key will be pointing to what it was pointing to before - the Active or Historical cloud's version. |
課題
| サーバーでのキー | クラウドでの状態 | 優先対象 | 詳細 |
|---|---|---|---|
| アクティブ | 存在しない | N/A | There are no clashes, and the issue gets migrated. |
| アクティブ | アクティブ | N/A | Migration is not allowed, and pre-flight checks block it. This situation implies that the same project exists in the cloud. |
| アクティブ | 履歴として存在 | Server | The active version wins. After the migration, the link pointing to this issue will no longer redirect to the cloud's Active version but will render the server's migrated Active version. |
| 履歴として存在 | 存在しない | N/A | There are no clashes; the historical key gets migrated and will become a historical key for its active issue in the cloud. |
| 履歴として存在 | 履歴として存在 | クラウド | The server's historical key will be ignored. After the migration, this issue key will be pointing to what it was pointing to before - the cloud's version of the issue. |
| 履歴として存在 | アクティブ | クラウド | The existing Active cloud version will shadow the historical key from the server. The difference with the previous case is that we will still import the server's historical key as a history of its current server issue. Still, it will be inactive until you delete the Active issue or the Active project shadowing it. |
What we have planned for the future
The clash resolution logic described above should be sufficient for most migration scenarios.
Still, as demonstrated above, depending on your situation, it may or may not result in changes to links post-migration.
今後は移行ロジックにさらなる柔軟性を提供し、競合の解決においてサーバーとクラウドのどちらを優先すべきかをユーザーが選択できるようにすることを予定しています。