The Bulk Move operation allows multiple issues to be moved at once. It is possible to move a selection of
issues to a new project with the ability to select a new issue type in certain cases. The issues are selected through
the Issue Navigator as discussed above. Since JIRA 3.4, you can move issues with different issue types to new target project and issue types all at once.
The operation is completed as follows:
- Select Projects and/or Issue Types
- Select Projects and/or Issue Types for Sub-Tasks
- Select status migration mappings for invalid statuses
- Select values for required or invalid fields
- Confirm changes to be made and complete the operation
Note that steps 3 and 4 will occur once for each different target project and issue type combination.
The bulk move operation can be performed on both standard issues and sub-task issues. Standard issues can be moved to another project and issue type, whereas a sub-task can only have its issue type changed.
It is not possible to select both a sub-task and its parent to bulk move. This is so to adhere to the
parent/sub-task relationship (i.e. the sub-task is always located in the same project as the parent issue). Any sub-tasks of selected parent issues which were also selected will be automatically discarded from the move.
For example, you have issue B being a sub-task of issue A and you try to bulk move both A and B simultaneously. You will see a warning message (see below) and will be prompted to select a target project and issue type for issue A. If you select a new project for A, you will be prompted to move the sub-task to a new issue type based on issue A's new project. If you don't change the project for issue A, the sub-task will not be required to be moved.
|
Select Projects and Issue Types
| |
| | |
The first step of bulk move is to choose what projects and issue types you'll move your issues to. The target project and issue type will determine whether extra steps will be required to migrate statuses and fields.
This screen shows all selected issues grouped by their current project and issue type. You can either select a new project and issue type for each one or choose to move all standard issues to a single project and issue type. To do this, select the check box with the label Use the above project and issue type pair for all other combinations and the selected project / issue type will apply. Note that this will not apply to sub-tasks since they cannot be moved to a standard issue type.
|
Select Projects and Issue Types for Sub-Tasks
| |
| | |
If you are moving issues with sub-tasks to another project, you'll also need to move the sub-tasks to the new project. On this screen you can elect to change the issue types of the sub-tasks being moved if you need to.
As multiple workflows can be active simultaneously within Enterprise Edition, some statuses associated with the collection of selected issues may not
be valid in the target workflow. In this case, JIRA allows the user to specify a mapping from invalid statuses to those available in the the target workflow.
This step of the wizard will only appear if you have invalid statuses. If you are moving issues to different projects and issue types at the same time, you will complete this step as well as the next for each of the different target project and issue type. To help you easily keep track of your progress, the current context, that is the target project and issue type, is highlighted in the left hand pane.
In order to adhere to the field layout scheme associated with the target project and issue type, it may be necessary to update/populate required fields.
For example, if one of the selected issues does not have a value for a required component and version fields, JIRA prompts the user to enter a suitable value.
It is possible to retain original field values that are valid in the target destination by checking the Retain
checkbox associated with the field. For example, some issues may already include a valid custom field value - these values can be retained, while
issues that require an update will adopt the value specified on the field update screen.
-
Checked: the original value is retained where possible. The field will not be updated with the
specified new value.
-
UnChecked: all fields will be updated with the specified new value.
When all move parameters - e.g. target project, status mappings and field updates - have been specified for all issues, the user is presented with a confirmation screen displaying all changes that will be made to the issues being moved. The following details are displayed:
-
Issue Targets: the target project and issue type
-
Workflow: the target workflow and invalid status mappings
-
Updated Fields: new values for fields that require updating
-
Removed Fields: values to be removed in fields that are not valid in the target
The issues will only be moved once the Confirm button is clicked from the confirmation page. If the operation is exited
anytime before this step, no changes will be made to the issues.