Issue Migration - 4.x
Description
The Update issues post function allows the issue type to be changed. This works fine by default when the workflow is the same for both issue types. However, in cases where the new issue type has a different workflow, Jira needs to migrate the issue to the new workflow. This requires a new parameter to specify the target status for the migrated issue in the new workflow. Otherwise, the issue type change cannot be made and an error is logged in the Jira application log. This capability is supported on release 2.6 or higher. This page describes how this works.
Details
To change the workflow of an issue, the issue needs to be migrated (moved) to the new workflow. When this case arises, we need to know what issue status to use in the new workflow. If this is a possible case in your use of the post function, you should provide this additional configuration to prevent the error from occurring and failing the change requested. If the new status is not provided or is not valid, an error is logged to the Jira application log and no changes are made for this post function.
Supported | Issue Type | New Issue Type |
|---|---|---|
Standard issue | Standard issue | |
Sub-task | Standard issue | |
Standard issue | Sub-task |
Configuration
Field | Value | Description | Examples |
|---|---|---|---|
Migrated status | Value representing a valid status in the workflow of the target project and issue type | Only used for issues requiring migration due to an issue type change. |
|
Post Function Ordering
It is important to correctly order the Update issues post function when a migration is possible. The migration must occur after the status is set and so the post function must follow that in the list.
Order after: Set issue status to the linked status of the destination workflow step.
Example
Suppose you have the following workflow:
For issues with type Bug: Open → In Progress → Close
For issues with type New Feature: ToDo → Work In progress → In Review → Close
Now, in a transition you have a need to update the issue type of some issue from Bug to New Feature. In this scenario, the change is not made unless the target issue type has a status to migrate to. This either needs to be specified explicitly in the configuration or the current status of the issue must match a status in the target workflow.
This is accomplished using the Target issue status name or id field.
Different statuses
If the target status needs to be different depending on the current status, there are a couple of techniques for dealing with this:
If the target status always matches the source status, then leave blank and that is used.
Use conditioning with multiple configurations to cover the unique cases.
Use Substitution variables to help construct the correct status name from the original status for instance - only possible if the wording of the status works out .
Log a request with our support team.
Confluence®, Jira®, Atlassian Bamboo®, Bitbucket®, Fisheye®, and Atlassian Crucible® are registered trademarks of Atlassian®
Copyright © 2005 - 2024 Appfire | All rights reserved. Appfire™, the 'Apps for makers™' slogan and Bob Swift Atlassian Apps™ are all trademarks of Appfire Technologies, LLC.