Page tree

Documentation for Structure version 4.2 and patch releases. Version Index

Skip to end of metadata
Go to start of metadata

When copying a structure, you can turn on Clone Issues parameter and have Structure plugin create a copy (clone) of every issue in the original structure.

How Issue Cloning Works

Each issue in the original structure is cloned by creating a new issue with the same summary, description, and the same value for every other field, including custom fields. There are a few exceptions to this rule, however:

  • 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.
  • If you clone issues to a different project, and some custom fields of the original issues are not available in that project, the values of those custom fields are not copied.
  • If you clone issues to a different project, and some field values of the original issues are not available in that project, those values are removed. For example, this may happen to the Components field, or to the fields that take versions as values.

Cloning issues to a different project may even be impossible, 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 that every issue in the copied structure satisfies them.

In any case, Structure does its best to verify that it can indeed 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 even a single issue cannot be cloned (for example, if you do not have the Create Issues permission for a certain project), then the operation stops before creating any clones.

On a 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.

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.

Cloning Parameters

   


Additional parameters may be specified for the cloning process:

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
Summary Suffix

Let you modify the summary of the clones. If the resulting summary gets longer than the JIRA limit (255 characters), it will be truncated.

Labels

Space-delimited labels to be added 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 JIRA server).

Clone JIRA sub-tasks of the cloned issues

Let's say the copied structure contains issue A-1. In JIRA, A-1 has a subtask A-2. But this subtask is not in the structure. If this option is selected, A-2 will also be cloned. If the option is not selected, A-1 will be cloned without the subtask.

Copy issue links

If selected, all issue links and remote issue links will be copied. If a link exists between two issues, which both are cloned, then the new link will be created between clones of the original issues.

If you use Link Back option, then the links of the type selected for linking back to original issues will not be copied.

If you have JIRA Agile (GreenHopper) 6.1 or later installed, its Scrum board Epic-Story relationships are also copied when you select this option. The rule is the same as for issue links:

  • If you clone an epic together with its stories, the cloned stories will be added to the cloned epic.
  • If you clone the stories alone, the clones will be added to the original epic.

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 the issue's project.

Required Permissions

  • To be able to clone structured 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 JIRA administrator - see Administrator's Guide.)
  • You need to have Create Issue permission in the projects where clones are created. If you specify 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, issue clone 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 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 GreenHopper's Epic-Story relationships.

Executing Bulk Cloning

When you press Start Cloning button, a background process starts on JIRA server, which performs the following:

  1. Copy original structure's hierarchy and store it in memory.
  2. Check all necessary permissions required for cloning.
  3. Clone all issues.
  4. Create a structure and fill it up with the cloned issues.

At step 2 the cloner process might discover some problems. If critical problems are discovered, an error message is shown and process is aborted. If non-critical problems are discovered, then 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.

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 usually takes reasonable time.

As cloning proceeds, progress bar is shown on the screen. When cloning is done, the resulting structure is opened for modification of its name and permissions.

Checking Clone 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 Manage Structures page and locate your 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 cloning progress page.

Cancelling Cloning

You can cancel cloning process from the cloning progress page by pressing Cancel link.

Issues that have already been created by the cloning process will be assembled into a special structure marked "[Cancelled Cloning Result]" in the structure name. You can use Bulk Change to quickly delete the unwanted issues.

Cloning Queue

Cloning issues can place considerable load on JIRA server. To avoid overloading 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.