Copying Structure and Cloning Issues
When copying a structure, you can turn on the Clone Issues parameter and have Structure create a copy (clone) of every issue in the original structure.
Issues added to a structure by Generators will not be cloned. To clone issues added by generators, create a new structure and copy all the issues from the original structure into the new structure, using Double Grid Mode. Then copy the new structure instead.
How Issue Cloning Works
Each issue in the original structure is cloned by creating a new issue with the same:
- summary
- description
- field values, including custom fields
With the following exceptions:
- The Status field is not copied. The cloned issues are always created in the initial status, according to each issue's project and workflow scheme.
- If a field is not present on the Create Issue screen, its value is not copied. The cloned issues will have the default value for that field instead.
- Archived versions are removed from Affects Versions, Fix Versions, and custom fields that have versions as values.
Additionally, when cloning issues to a different project:
- If custom fields for the original issues are not available in the new project, the values of those custom fields are not copied.
- If field values of the original issues are not available in the new project, those values are removed. For example, this may happen to the Components field, or to fields that take versions as values.
- In some cases, cloning issues to a different project may not be possible. For example, when a certain field is required in the target project, but absent (or not required) in the source project. If this is the case, you will need to either change the target project restrictions or make sure every issue in the copied structure satisfies them.
Structure does its best to verify that it can clone each issue in the original structure before it begins the actual cloning. If Structure detects a potential data loss (for example, because one of the custom fields is absent in the target project), it warns you and lets you decide whether you want to continue. If no issues can be cloned (for example, if you do not have Create Issues permission for the new project), the operation stops before creating any clones.
On the rare occasion when permissions or other restrictions are changed while the cloning operation is in progress, the operation may still fail after the initial checks.
Cloning Parameters
When Clone Issues is selected, you can specify a number of additional parameters.
Create in Project | Lets you specify a project for the new issues, different from the project the issues currently belong to. If not specified, every new issue is created in the same project as the original issue. |
Summary Prefix | Lets you modify the summary of the clones. If the resulting summary gets longer than the Jira limit (255 characters), it will be truncated. |
Labels | Lets you add space-delimited labels to the cloned issues. (Already existing labels are preserved.) |
Link Back | If specified, every new issue will be linked with its original issue. |
Copy comments | If selected, all comments are also copied. If not selected, new issues will have no comments. |
Copy attachments | If selected, attachments are copied (the actual files are copied on the Jira server). |
Clone Jira sub-tasks of the cloned issues | If selected, when issues have sub-tasks in Jira which are not also in the structure, those sub-tasks will be cloned as well. For example, issue A-1 has sub-task A-2 in Jira. A-1 is in the structure being copied, but A-2 is not. With this option selected, A-2 will also be cloned. Otherwise, A-1 will be cloned without the sub-task. |
Copy issue links | If selected, all issue links and remote issue links will be copied. If a link exists between two issues, and both are cloned, then the new link will be created between the clones. If you use the Link Back option, then the links of the type selected for linking back to original issues will not be copied. Scrum board Epic-Story relationships are also copied when you select this option. The rule is the same as for issue links:
|
Copy watchers | If selected, the users watching an original issue will be added to the watcher list of the clone. |
Notifications | If selected, an email may be issued for every created issue, depending on the Jira notification scheme for each issue's project. |
Required Permissions
The following permissions are required to copy a structure with issue cloning:
- To be able to clone structure issues, you need Bulk Change global permission.
- Because the result of cloning is a new structure, you also need to be allowed to create new structures. (Configured by the Jira administrator - see Administrator's Guide.)
- You need to have Create Issue permission in the projects where the clones are created. If you specify the Create in Project option, the issues will be created only in the specified project. Otherwise, clones are created in the same projects as their respective original issues.
- Users in the Assignee field of the original issues will have to have Assignable User permission in the target project – otherwise, cloned issues cannot be assigned to that user and will be assigned by default.
- If you don't have Modify Reporter permission, you won't be able to set the value of the Reporter field in the cloned issues. Instead of the original reporter, you will be the reporter of the issue clones.
- You need to have Add Comments permission to copy comments, Link Issues permission to copy issue links or use Link Back, Create Attachments permission to copy attachments, Manage Watchers permission to copy watcher lists, and Edit Issue permission to copy Epic-Story relationships.
Executing Bulk Cloning
When you press the Start Cloning button, a background process starts on the Jira server, which performs the following:
- Copies the original structure's hierarchy and stores it in memory
- Checks all necessary permissions required for cloning
- Clones all issues
- Creates a new structure and fills it with the cloned issues
At step 2, the cloning process might discover some problems. If critical problems are discovered, an error message is shown and the process is aborted. If non-critical problems are discovered, warnings are shown and user input is required. The warnings may suggest that cloning may continue, but the resulting issues might not be exact copies. After your confirmation, the process continues.
As cloning proceeds, a progress bar is shown on the screen. When cloning is done, the Edit Structure page is opened for the resulting structure, so you can make any necessary adjustments to its name and permissions.
Cloning issues is potentially a long operation. Cloning a structure with tens of thousands of issues may take an hour or more. Cloning smaller structures should take considerably less time.
Checking Cloning Progress
When cloning has started, you can navigate away from the cloning progress page. To see the progress and get back to the progress screen, open the Manage Structures page and locate the original structure. It should show that the structure is being copied.
When cloning is completed, or if there are warnings or questions from the cloning process, the link will read "Waiting for input". Click the link to open the cloning progress page.
Cancelling Cloning
You can cancel the cloning process from the cloning progress page by pressing the Cancel link.
Issues that have already been created by the cloning process will be assembled into a special structure named "[Cancelled Cloning Result]". You can use Bulk Edit to quickly delete the unwanted issues.
Cloning Queue
Cloning issues can place considerable load on a Jira server. To avoid overloading the server with cloning jobs, there is a limit to the number of cloning processes that can happen simultaneously. If this limit is exceeded, your cloning process will initially be in "waiting" state, pending for other cloning processes to finish.