Use case:
The user wants to migrate a project characterized by substantial variations in the status and workflows associated with different issue types. In essence, they aim to transition a project where each issue type operates under entirely separate workflow structures, all within the same project.
What happens when trying to configure a profile in TFS4JIRA for such a use case?
Status and statuses mapping allows multiple-to-one or one-to-multiple mapping, but not many-to-many.
...
Losing the links between the issues would not be an option for our client. Especially when talking about Epics and subtasks, that information is essential for the workflow and hierarchy of the issues. They also didn’t want to use the Self-Hosted version because it involves installation on a Windows machine.
\uD83D\uDCD8 Workaround
The third option is using only one profile. That would mean that within the same profile, the links between issues would not be lost. The user would need to respect Hierarchy and migrate the issues in the following order:
1. Epics
2. Bugs, Tasks, Stories, …
3. Subtasks.
Why would this work? Because it’s a one-time migration, the user doesn’t need live synchronization, so it’s okay if the mapping of already synchronized issues is lost/edited as it will no longer be used.
Instructions:
Create a profile with all the mapping and configurations specific to Epics
Apply a filter in Filters, Jira JQL
issueType=Epic
...
| Note |
|---|
The challenges/cons are:
|
\uD83D\uDCCB Related articles
| Filter by label (Content by label) | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|