Uploaded image for project: 'Jira Platform Cloud'
  1. Jira Platform Cloud
  2. JRACLOUD-29704

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

XMLWordPrintable

      NOTE: This bug report is for JIRA Cloud. Using JIRA Server? 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.

        1. Component Maker Batch Upload-01(30).xlsx
          96 kB
        2. Metal setter Batch Upload-01(30).xlsx
          97 kB
        3. Wax Setter Batch Upload-01(30).xlsx
          96 kB

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

            Maik Winter added a comment -

            also happens on v6.3.10

            Maik Winter added a comment - also happens on v6.3.10

            Sheral Hewes added a comment -

            I removed the validator and the issue is still linking to itself. This is not a sub-task. It is a regular issue.

            Sheral Hewes added a comment - I removed the validator and the issue is still linking to itself. This is not a sub-task. It is a regular issue.

            Bob Swift added a comment -

            This affects 5.1.x through 6.1.x (sorry, I can't update the affects versions). As Eric mentioned above, it is important to test the subtask cloning related scenarios as well.

            Bob Swift added a comment - This affects 5.1.x through 6.1.x (sorry, I can't update the affects versions). As Eric mentioned above, it is important to test the subtask cloning related scenarios as well.

            Eric Dangoor added a comment -

            The fix for JRA-23883 seems at least to have addressed the sub-task issue but without reporting failures to the user even though they are visible in the log file. Also the main issue still gets a cloner link pointing to itself.

            Eric Dangoor added a comment - The fix for JRA-23883 seems at least to have addressed the sub-task issue but without reporting failures to the user even though they are visible in the log file. Also the main issue still gets a cloner link pointing to itself.

            Eric Dangoor added a comment -

            Our system is getting corrupted with many of the spurious links, especially the sub-task links which can't be deleted from the interface. Is this likely to be fixed anytime soon ?

            Eric Dangoor added a comment - Our system is getting corrupted with many of the spurious links, especially the sub-task links which can't be deleted from the interface. Is this likely to be fixed anytime soon ?

            Eric Dangoor added a comment -

            JIRA should report the failure to create the clone to the user, specifying the reason for the failure.

            Eric Dangoor added a comment - JIRA should report the failure to create the clone to the user, specifying the reason for the failure.

            Eric Dangoor added a comment -

            If the original issue has sub-tasks and the Clone Sub-tasks option is checked then the original issue also ends up with sub-task links to itself !

            Eric Dangoor added a comment - If the original issue has sub-tasks and the Clone Sub-tasks option is checked then the original issue also ends up with sub-task links to itself !

            Dieter Greiner added a comment - - edited

            Seems an easy change ... so why not fix this in 5.2.x ?
            This would help us a lot to reduce to avoid support calls

            Dieter Greiner added a comment - - edited Seems an easy change ... so why not fix this in 5.2.x ? This would help us a lot to reduce to avoid support calls

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

                Created:
                Updated:
                Resolved: