Bulk Operations

1. From the Issue Navigator, perform a search with the required filters to produce an issue result set.
2. The Bulk Change option in the Issue Navigator menu provides access to the bulk operations. If the result set spans a number of pages, it is possible to select all issues within the result set to be considered for the bulk operation. Alternatively, all issues on the current page can be selected for the bulk operation.
3. The next screen allows the selection of the issues that the bulk operation is to be performed on.
4. The next screen allows the bulk operation to be selected - Delete, Move or Edit.
5. If the Delete operation is selected, the final step is confirmation of the delete operation on the issues selected.
6. If the Edit operation is selected, the next screen provides a list of the available edit operations that can be performed on the issues selected. Some operations may be unavailable as noted above.
7. After selecting the required Edit operation(s), the final step is confirmation of the edit operation(s) on the selected issues.
8. If the Move operation is selected, the next screens allow a target project (and issue type if Enterprise edition) to be selected, with the ability to migrate workflow statuses and update required fields as necessary. Further details on this operation can be found here.

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. The operation is completed as follows (not all steps are required):

1. Select Project and/or Issue Type
2. Select status migration mappings for invalid statuses
3. Select values for required or invalid fields
4. Confirm changes to be made and complete the operation

The bulk move operation can only be completed on a selection of parent issues or sub-task issues. It is not possible to complete the operation on a selection of issues containing both parent and sub-task issues. This restriction is enforced so as to adhere to the parent/sub-task relationship (i.e. the sub-task is always located in the same project as the parent issue).

In such an instance where both parent and sub-task issues have been selected, it is possible to choose a subset of issues - selecting to move only the parent or sub-task issues.

Once the parent issue collection is selected, all parent issues and their associated sub-tasks will be moved. If the sub-tasks are selected, only the sub-tasks will be updated during the move operation. It is only possible to update the issue type when moving a collection of sub-tasks.

Once the collection of issues to be moved has been confirmed, it is possible to select the target project and/or issue type to which the issues will be moved. Standard and Professional Editions only allow the selection of the target project. Enterprise Edition allows the target project and issue type to be selected. With a collection of sub-tasks, it is only possible to select a new sub-task type.

All sub-tasks associated with the selected parent issues will be moved to the target project and retain the current sub-task type.

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.

Mappings can be specified for parent and sub-task issue types.

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 custom field, 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, the user is presented with a confirmation screen displaying all changes that will be made to the issues to be 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 Next button is clicked from the confirmation page. If the operation is exited anytime before this step, no changes will be made to the issues.

The ability to move sub-tasks is limited in a number of ways. Some of these limitations will be addressed in future releases.

• Sub-Task Collection: if the selected issues contain only sub-tasks, it is only possible to select a target issue type.
• Field Update: not all fields will be updated for sub-tasks, even if the field layout specifies a particular field to be required. Components, Fix Versions and Affects Versions are cleared without the ability to set a new value.
• Confirmation Screen: in a collection of parents including associated sub-tasks, the changes to the sub-task issues are not displayed.