We couldn't load all Actvitity tabs. Refresh the page to try again.
If the problem persists, contact your Jira admin.
IMPORTANT: JAC is a Public system and anyone on the internet will be able to view the data in the created JAC tickets. Please don’t include Customer or Sensitive data in the JAC ticket.
Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-29704

When clone operation fails during create, a self-referencing cloners link is added to the original issue

      NOTE: This bug report is for JIRA Server. Using JIRA Cloud? See the corresponding bug report.

      Summary

      If a clone operation fails during the create transition (such as when a validator on the Create transition stops the issue creation), JIRA adds a self-referencing link to the original issue (only if the Cloners link type is specified, of course).

      Steps to Reproduce

      1. Create a validator such as Required Field(s) using JIRA Suite Utilities on the Create Issue Transition.
      2. Setup an issue so that it does not have those requirements. For example, set the requirement to affects version, then remove the affects version from the issue.
      3. Attempt to clone the issue.

      Expected Results

      The issue does not create a clone and notifies the user why.

      Actual Results

      The issue is not cloned, however an issue link is created to itself. Nothing notifies the user of failure.

      Workaround

      Fix the validator for that issue and then clone it. Using the above example that would mean adding an affects version.

      Notes

      After some investigation, this appears to be caused by the following code in the doExecute() method of the CloneIssueDetails class:

      // Create link between the cloned issue and the original - sequence on links does not matter.
      final IssueLinkType cloneIssueLinkType = getCloneIssueLinkType();
      if (cloneIssueLinkType != null)
      {
          issueLinkManager.createIssueLink(getOriginalIssue().getId(), getIssue().getLong("id"), cloneIssueLinkType.getLong("id"), null, getLoggedInUser());
      }
      

      By simply calling the getOriginalIssue() and getIssue() methods, there is a built-in assumption that the clone creation succeeded. However, if the creation failed, these two methods will return the same issue (originalIssue is first set using the getIssue() result).

      Please add a check here that the clone creation actually succeeded, or at least that getOriginalIssue() and getIssue() are resulting in different and valid issues.

            Loading...
            IMPORTANT: JAC is a Public system and anyone on the internet will be able to view the data in the created JAC tickets. Please don’t include Customer or Sensitive data in the JAC ticket.
            Uploaded image for project: 'Jira Data Center'
            1. Jira Data Center
            2. JRASERVER-29704

            When clone operation fails during create, a self-referencing cloners link is added to the original issue

                NOTE: This bug report is for JIRA Server. Using JIRA Cloud? See the corresponding bug report.

                Summary

                If a clone operation fails during the create transition (such as when a validator on the Create transition stops the issue creation), JIRA adds a self-referencing link to the original issue (only if the Cloners link type is specified, of course).

                Steps to Reproduce

                1. Create a validator such as Required Field(s) using JIRA Suite Utilities on the Create Issue Transition.
                2. Setup an issue so that it does not have those requirements. For example, set the requirement to affects version, then remove the affects version from the issue.
                3. Attempt to clone the issue.

                Expected Results

                The issue does not create a clone and notifies the user why.

                Actual Results

                The issue is not cloned, however an issue link is created to itself. Nothing notifies the user of failure.

                Workaround

                Fix the validator for that issue and then clone it. Using the above example that would mean adding an affects version.

                Notes

                After some investigation, this appears to be caused by the following code in the doExecute() method of the CloneIssueDetails class:

                // Create link between the cloned issue and the original - sequence on links does not matter.
                final IssueLinkType cloneIssueLinkType = getCloneIssueLinkType();
                if (cloneIssueLinkType != null)
                {
                    issueLinkManager.createIssueLink(getOriginalIssue().getId(), getIssue().getLong("id"), cloneIssueLinkType.getLong("id"), null, getLoggedInUser());
                }
                

                By simply calling the getOriginalIssue() and getIssue() methods, there is a built-in assumption that the clone creation succeeded. However, if the creation failed, these two methods will return the same issue (originalIssue is first set using the getIssue() result).

                Please add a check here that the clone creation actually succeeded, or at least that getOriginalIssue() and getIssue() are resulting in different and valid issues.

                        pklimkowski@atlassian.com Piotr Klimkowski (Inactive)
                        7ce5f856ba69 Kavian Moradhassel
                        Votes:
                        25 Vote for this issue
                        Watchers:
                        29 Start watching this issue

                          Created:
                          Updated:
                          Resolved:

                            pklimkowski@atlassian.com Piotr Klimkowski (Inactive)
                            7ce5f856ba69 Kavian Moradhassel
                            Affected customers:
                            25 This affects my team
                            Watchers:
                            29 Start watching this issue

                              Created:
                              Updated:
                              Resolved: