What you can do with Epic Clone?
- Jonas Moehringer
When you open the Epic Clone dialog, you have the option to modify the cloning settings for the parent issue (the one you accessed the dialog from) on the initial screen.
Target project selection
Cloning typically occurs within the same project by default. Nonetheless, Epic Clone offers the flexibility to clone across projects as well. By selecting the checkbox, you can search and select a new target project for the cloned issues.
Notes for target project selection:
Only projects accessible to you will be displayed in the selection list.
When you switch the target project, the system promptly verifies if the issue type of the source issue is present in the newly selected project and checks your permission to create issues within that project. If either condition is not met, an error message will be displayed.
Dialog if target project is a team-managed project:
Dialog if target project is a company-managed project (Epic):
Edit fields
Summary: Define the summary for the cloned issue. The original issue's summary is automatically shown.
Epic Name: In company-managed projects, epics come with an epic name field. When you clone an epic from a company-managed project, you have the option to specify the epic name for the new epic. By default, the epic name from the original epic is displayed in such instances.
Find in description: You have the option to locate specific text within the description field and substitute it with different content for the duplicated issue. This feature proves particularly beneficial when utilizing placeholders in the description of template issues. It allows for a seamless transition from placeholders to the desired text upon cloning.
Replace with: Text you want as replacement if find text is found in description. Leave this field blank if you want to remove the find text from the description. If find in description field is empty or when the find text is not found, nothing happens to the description of the cloned issue. Its value will be cloned like all other fields.
Clone Attachments: If the source issue contains attachments and you have permission to create attachments in the target project, you have the option to choose whether to clone the attachments. By default, it is set to clone attachments. If you do not see the field, it indicates that either the source issue lacks attachments or you lack the privilege to add attachments in the target project.
Parent Link Options: When cloning a source issue with an established parent link, you have the option to decide whether you wish to replicate this parent link to the newly created issue. This particular field is only visible in the presence of an existing parent link.
Labels: Existing labels of the source issue will be displayed by default. You can select additional labels from the existing ones in your instance or add additional new custom labels. The labels inserted in the field will be added to all created issues.
Components: In company-managed projects, you have the ability to define and choose components within the issues. When cloning to a company-managed project, you can conveniently select components from the ones already present in the target project. This selection list automatically updates each time you choose a new target project. However, if you opt for a team-managed project as the target, the component field vanishes since components are not supported in team-managed projects.
Assignee new: Assign a user to the cloned issue. The default value shows the current assignee of the source issue. You can only choose users with permission to be assigned to issues in the target project. If you switch the target project and the current assignee lacks this permission, the field will reset. Not selecting a user will lead to an unassigned cloned issue.
Fix Versions: In company-managed projects, releases can be designated and chosen in the fix version field. When cloning to a company-managed project, you have the option to select releases to assign in the fix version field from the defined releases in the target project. This list of selections will be automatically filled each time you pick a new target project. However, if you designate a team-managed project as the target project, the field will vanish since releases are not supported in team-managed projects.
Due date: Select a due date to be set.
Original Estimate: In company-managed projects, you have the ability to update the original estimate field with a new value. It is important to adhere to the Atlassian time tracking format when entering the new value. Failure to follow the correct format will result in an error message, preventing you from advancing to the next screen. For instance, a valid format could be "2w 3d 4h," representing 2 weeks, 3 days, and 4 hours.
By clicking on "next," you will be directed to the second page. Here, you can specify the child or linked issues that you wish to replicate along with the source issue. The progress indicator on top can also be clicked to proceed to the next screen.
Child issues
Child Issues - keep in source project
When dealing with child issues originating from various projects, you have the option to choose between cloning them within their original project or transferring them all to the designated target project. Simply activate the toggle to retain these cloned issues in their respective projects. By default, all issues will be duplicated to the specified target project.
Link between source issues and cloned issues new
This option can be enabled to establish an issue link between original issues and cloned ones. Similar to the "clones / is cloned by" relationship familiar in the default Jira clone function, you can also define such a link for the issues cloned using Epic Clone. Upon activation, a dropdown menu appears, allowing you to choose the link type for the issue links.
Child Issues - modify issue summaries new
The find and replace functionality for child issue summaries allows users to search for a specific word or phrase and replace it with another term across all child issue summaries. This feature streamlines the process of updating information consistently within multiple child issues.
For instance, in the provided example screenshot, the word '<type of user>' is replaced with 'developer' in all child issue summaries. This capability enhances efficiency by enabling users to make bulk changes to text elements swiftly and accurately. The preview of the issues summary is displayed immediately when the search term is found.
Moreover, users can also add a prefix and suffix to all child issue summaries. This additional functionality offers flexibility in customizing the content of the summaries according to specific requirements or conventions. By incorporating prefixes and suffixes, users can further tailor the information displayed in the child issue summaries to align with their project needs.
Child Issues - select for cloning
Choose which child issues to clone along with the parent. The checkbox list displays the issue type, key, and summary. Child issues can either be epics within an epic or sub-tasks for other issues.
Only the issues with an issue type existing in the target project will be selectable.
You can only select sub-tasks for which the parent issue has been selected as well for cloning. If you deselect a parent, its sub-tasks won’t be selectable anymore.
Child Issues - edit fields
Like for the parent issue, it is also possible to edit certain fields for the child issues you want to clone.
Clone Attachments: If the child issue contains attachments and you possess the permission to create attachments in the target project, you have the option to choose whether to replicate the attachments. The default setting is to replicate the attachments. If you do not see the field, it indicates that either the specific child issue lacks attachments or you lack the authorization to include attachments in the target project.
Expand and edit: By clicking on the expand icon next to the issue summary, you can reveal more details about the various child issues. When expanded, additional fields along with their corresponding values for the source issue will be shown. Clicking on the edit icon located on the right allows you to make inline edits to the following fields:
Summary: Revise the child issue's summary.
Assignee: Choose from users with the necessary permission to be assigned to issues in the target project.
Original estimate: Define a fresh original estimate for the child issue. Ensure the added value follows the Atlassian time tracking format (e.g. 4w 2d for 4 weeks and 2 days).
Due date
Story points: This attribute is exclusive to stories.
Upon clicking the save button, the updated values will appear on the cloning screen and will be applied to the cloned issues.
Child Issues - reorder new
The Epic Clone feature allows for convenient reordering of child issues in the list through a simple drag-and-drop functionality. By rearranging the sequence of child issues, users can define a new order that will be applied when cloning the issues. Additionally, the flexibility extends to sub-tasks, enabling users to easily change their parent issue within the list using the same drag-and-drop method.
In cases where the position of an issue becomes invalid, such as placing a sub-task at the top of the list without a parent, the system promptly responds with an error message displayed at the top of the issue list. This error notification ensures that the issue's position is reset to a valid state, maintaining the integrity of the cloning process.
Child Issues - reset
To revert any modifications made on the screen or rearrangements of child issues, simply click on the reset icon located at the top right corner. This feature is visible only when alterations have been applied. By clicking the reset icon, the child issues on the page will be reloaded, and the field values will be restored to their default values.
Linked Issues - Parent Issue
If the source issue has other linked issues, they will appear in a checkbox list below the child issue list on the dialog. You have three clone link options to choose from:
Clone Link Options:
Clone links only: This option links the target issue to the same issues as the source issue.
Clone linked issues: This option copies and links the issues linked to the source issue to the target issue.
Don’t clone links: With this option, no action is taken on the links. They are not considered for cloning.
Following these options, you will find a checkbox list of linked issues. Similar to child issues, only the checked links in this list will be taken into account.
By default, the last option is chosen. In this scenario, no issues can be selected in the checkbox list.
Linked Issues - Child Issues
When dealing with issues linked to the child issues displayed, the process can become a bit more complex. However, it is possible to replicate these links. There are three choices available for cloning child issue links:
Clone child issue links: This option ensures that the cloned child issues will be linked to the same issues as the child issues of the source issue.
Recreate internal links after cloning: Internal links refer to connections among child issues (refer to the explanation below for further details). Opting for this alternative will result in the recreation of internal links after cloning. For instance, if child issue 1 is linked to child issue 2 under the source issue, then the clone of child issue 1 will be linked to the clone of child issue 2 subsequently.
Don’t clone links: This choice means that no action will be taken regarding child issue links. They will not be considered for cloning at all.
Following these options, you will encounter a checkbox list of issues linked to child issues. As mentioned earlier, only the links that are checked in this list will be taken into account.
By default, the last option is preselected. In this scenario, no issues can be selected in the checkbox list.
What does external/internal links of child issues mean?
As the cloning of child issue links can become complex, here is a table with examples for the different possibilities. Let’s assume we have a source issue with child issues A, B and C, and issues D and E, which are outside of the source issue, so not child issues.
Source Issue
Child: Issue A
Child: Issue B
Child: Issue C
Issue D
Issue E
Link | Type | Child Issue selected for cloning | Selected link option for child issue links | Result |
|---|---|---|---|---|
Issue A → Issue D | external | yes | Clone child issue links | Cloned issue A → Issue D |
no | Clone child issue links | no cloned issue A, no link created | ||
not relevant | Recreate internal links after cloning | no link created as link is not internal | ||
Issue B → Issue C | internal | yes | Clone child issue links | Cloned issue B → Issue C |
no | Clone child issue links | no cloned issue B, no link created | ||
Issue B: yes Issue C: yes | Recreate internal links after cloning | Cloned issue B → Cloned issue C | ||
Issue B: yes Issue C: no | Recreate internal links after cloning | no link created |
The child issue link checkboxes are only selectable when cloning of the link is possible at all. As an example, if you select to recreate internal links, all checkboxes for external links are disable and only internal links are selectable. If you deselect one of the checkboxes for child issue cloning, recreation of the respective internal link is no longer possible. Therefore, the related child issue link checkboxes are disabled.
Only links between child issues on the same level are considered as internal. So, only between child issue and child issue, or sub-task and sub-task. A link between a child issue and a sub-task of another child issue is considered as external.
If you have finished your settings, click on run to start the cloning. See this page for information on the result screen.