• Type: Bug
• Resolution: Fixed
• Priority: Low
• Component/s: Issue - View (Internal developer use only)
• Labels:

  • affects-cloud
  • affects-server
  • saigon
  • st10

1. Component Maker Batch Upload-01(30).xlsx

   96 kB

   25/Aug/2015 5:43 AM

2. Metal setter Batch Upload-01(30).xlsx

   97 kB

   25/Aug/2015 5:43 AM

3. Wax Setter Batch Upload-01(30).xlsx

   96 kB

   25/Aug/2015 5:44 AM

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

Monique Khairuliana (Inactive) made changes - 15/Aug/2019 5:41 AM

Workflow	Original: JIRA Bug Workflow w Kanban v6 - Restricted [ 1867488 ]	New: JAC Bug Workflow v3 [ 3360426 ]
Status	Original: Resolved [ 5 ]	New: Closed [ 6 ]

Eric S (Inactive) made changes - 14/Sep/2018 4:44 AM

Component/s		New: Issue [ 51491 ]
Component/s	Original: Issue - Clone [ 46601 ]

jonah (Inactive) made changes - 02/Apr/2017 10:08 AM

Description

Original: h3. 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). h3. Steps to Reproduce # Create a validator such as Required Field(s) using [JIRA Suite Utilities|https://marketplace.atlassian.com/plugins/com.googlecode.jira-suite-utilities] on the Create Issue Transition. # 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. # Attempt to clone the issue. h3. Expected Results The issue does not create a clone and notifies the user why. h3. Actual Results The issue is not cloned, however an issue link is created to itself. Nothing notifies the user of failure. h3. Workaround Fix the validator for that issue and then clone it. Using the above example that would mean adding an affects version. h3. Notes After some investigation, this appears to be caused by the following code in the _doExecute()_ method of the *CloneIssueDetails* class: {code:java} // 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()); } {code} 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.

New: {panel:bgColor=#e7f4fa}   *NOTE:* This bug report is for *JIRA Cloud*. Using *JIRA Server*? [See the corresponding bug report|http://jira.atlassian.com/browse/JRASERVER-29704].   {panel} h3. 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). h3. Steps to Reproduce # Create a validator such as Required Field(s) using [JIRA Suite Utilities|https://marketplace.atlassian.com/plugins/com.googlecode.jira-suite-utilities] on the Create Issue Transition. # 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. # Attempt to clone the issue. h3. Expected Results The issue does not create a clone and notifies the user why. h3. Actual Results The issue is not cloned, however an issue link is created to itself. Nothing notifies the user of failure. h3. Workaround Fix the validator for that issue and then clone it. Using the above example that would mean adding an affects version. h3. Notes After some investigation, this appears to be caused by the following code in the _doExecute()_ method of the *CloneIssueDetails* class: {code:java} // 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()); } {code} 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.

jonah (Inactive) made changes - 02/Apr/2017 10:08 AM

Link

New: This issue is related to JRASERVER-29704 [ JRASERVER-29704 ]

vkharisma made changes - 01/Apr/2017 7:41 PM

Project Import

New: Sat Apr 01 19:36:47 UTC 2017 [ 1491075407146 ]

Confluence Escalation Bot (Inactive) made changes - 16/Mar/2017 4:37 AM

Confluence Escalation Bot (Inactive) made changes - 20/Feb/2017 12:45 AM

Marty Henderson (Inactive) made changes - 18/Sep/2016 9:03 AM

Oswaldo Hernandez (Inactive) made changes - 21/Jul/2016 12:34 AM

Owen made changes - 07/Jul/2016 6:57 AM

Load more older events