• Create an issue
      • Under "More actions" choose clone
      • Accept the name of the cloned issue

      1. Expand the "Issue Links" of the cloned issue

      Expected: "This issue is cloned from:"
      Actual: "This issue is cloned by:". This is understood like this issue is cloned by the original.

      2. Expand the "Issue Links" of the original issue

      Expected: "This issue is cloned by:"
      Actual: "This issue clones:". This is understood a the issue clones whatever appears on the list.

      Note:

      This was fixed in JIRA 5.2.6 but the issues already cloned will remain with the wrong direction link. You can check how to fix those issues in this KB:

        1. IncorrectWordingWhenCloning.png
          31 kB
          Federico Silva Armas [Atlassian]
        2. 2013-03-11_0617.swf
          1.45 MB
          Bob Swift
        3. clonedby.png
          9 kB
          Mark Lassau
        4. cloners-link-clones.png
          12 kB
          Bob Swift
        5. cloners-link-was-cloned-to.png
          10 kB
          Bob Swift

            [JRASERVER-24563] Clone operation creates links in the wrong direction

            I see that this very old ticket is closed, but I'm still experiencing this behavior. You can see in this ticket https://maplight.atlassian.net/browse/NVE-317 that there are 3 tickets listed as "Cloned from" which isn't possible- this ticket was cloned TO those issues.

            I'm not sure how to attach a screenshot and it's likely that you can't see that ticket, so let me know if you need more details.

            Lauren Briskin added a comment - I see that this very old ticket is closed, but I'm still experiencing this behavior. You can see in this ticket https://maplight.atlassian.net/browse/NVE-317 that there are 3 tickets listed as "Cloned from" which isn't possible- this ticket was cloned TO those issues. I'm not sure how to attach a screenshot and it's likely that you can't see that ticket, so let me know if you need more details.

            The link in the "Note:" section of the description field (above) has been changed. The new link is:
            https://confluence.atlassian.com/display/JIRAKB/How+to+Fix+Links+in+Wrong+Direction+After+Cloning+an+Issue

            Steve Lemke added a comment - The link in the "Note:" section of the description field (above) has been changed. The new link is: https://confluence.atlassian.com/display/JIRAKB/How+to+Fix+Links+in+Wrong+Direction+After+Cloning+an+Issue

            MattS added a comment -

            Sadly, there are big chunks of JIRA code where things are private for no good reason. Trying to reuse the system gadgets is one case. I think the problem is that by default JIRA developers aren't thinking of people outside Atlassian extending their code - one more thing to remember. It would be nice to see this considered during code review though.

            MattS added a comment - Sadly, there are big chunks of JIRA code where things are private for no good reason. Trying to reuse the system gadgets is one case. I think the problem is that by default JIRA developers aren't thinking of people outside Atlassian extending their code - one more thing to remember. It would be nice to see this considered during code review though.

            I understand that it's part of jira-core, which isn't guaranteed to be useful for plugins. However, I would hope that Atlassian wouldn't go out of their way to make it difficult for plugin authors. In this case, making the method private is actually inconsistent with the rest of the class, so I'm just confused why they chose to implement it this way.

            There is what's guaranteed + supported, and then there's what is sensible. This isn't sensible, from what I can see.

            Alternatively, Atlassian could give us better plugin points to customize issue creation steps...but I suspect that's not going to happen anytime soon, either...

            Kavian Moradhassel added a comment - I understand that it's part of jira-core, which isn't guaranteed to be useful for plugins. However, I would hope that Atlassian wouldn't go out of their way to make it difficult for plugin authors. In this case, making the method private is actually inconsistent with the rest of the class, so I'm just confused why they chose to implement it this way. There is what's guaranteed + supported, and then there's what is sensible. This isn't sensible, from what I can see. Alternatively, Atlassian could give us better plugin points to customize issue creation steps...but I suspect that's not going to happen anytime soon, either...

            MattS added a comment -

            It may be public, and I would agree the new method should be public, but it's not part of the JIRA API.

            MattS added a comment - It may be public, and I would agree the new method should be public, but it's not part of the JIRA API.

            Atlassian, this "fix" was poorly executed, and you may want to revisit this.

            To begin with, you modified the precise lines of code referenced by JRA-29704 without paying any attention to that issue.

            More importantly, however, you've implemented your fix using the private method shouldReverseLink(IssueLinkType) in the CloneIssueDetails class. For those of us implementing custom create actions via plugin, you've locked us out of customizing this behaviour. Every other helper method in this class is public, and yet this new one is private...why?

            Kavian Moradhassel added a comment - Atlassian, this "fix" was poorly executed, and you may want to revisit this. To begin with, you modified the precise lines of code referenced by JRA-29704 without paying any attention to that issue. More importantly, however, you've implemented your fix using the private method shouldReverseLink(IssueLinkType) in the CloneIssueDetails class. For those of us implementing custom create actions via plugin, you've locked us out of customizing this behaviour. Every other helper method in this class is public, and yet this new one is private...why?

            markmielke added a comment -

            Bob: In making the words clearer, you've actually swapped the direction. "Is cloned by" ("A is cloned by B", therefore B is the clone) does not map to "Is a clone of" ("A is clone of B", therefore A is the clone).

            The situations sucks. I think the proposal as I understand it, whereby any customizations are left as is, but if the original configuration is used, then the link direction is swapped, makes sense.

            That said, I haven't yet upgraded past 5.2.5 yet for our instance that uses these, because I need to slow down and understand this well. Most likely, we're going to rename this entire link to "Copy" (possibly fixing the direction link at the same time) and stop using the "Clone" feature altogether as it doesn't work very well in most of our real world use cases. The Copy Plus plugin, especially with our customizations to it, is a lot more friendlier...

            markmielke added a comment - Bob: In making the words clearer, you've actually swapped the direction. "Is cloned by" ("A is cloned by B", therefore B is the clone) does not map to "Is a clone of" ("A is clone of B", therefore A is the clone). The situations sucks. I think the proposal as I understand it, whereby any customizations are left as is, but if the original configuration is used, then the link direction is swapped, makes sense. That said, I haven't yet upgraded past 5.2.5 yet for our instance that uses these, because I need to slow down and understand this well. Most likely, we're going to rename this entire link to "Copy" (possibly fixing the direction link at the same time) and stop using the "Clone" feature altogether as it doesn't work very well in most of our real world use cases. The Copy Plus plugin, especially with our customizations to it, is a lot more friendlier...

            Bob Swift added a comment - - edited

            I think the terminology is adding to the confusion. The bottom line is I think you have reversed the meaning of the link since the beginning of JIRA so anyone with existing link definitions is now reversed. Here is the terminology that makes it clearer:

            Bob Swift added a comment - - edited I think the terminology is adding to the confusion. The bottom line is I think you have reversed the meaning of the link since the beginning of JIRA so anyone with existing link definitions is now reversed. Here is the terminology that makes it clearer:

            I watched the video and it displays the same behaviour as I describe above:

            • The footer shows JIRA v5.2.6
            • After cloning DEMO-1, the video shows "DEMO-9 clones DEMO-1" and "DEMO-1 is cloned by DEMO-9"
            • Which is the correct behaviour

            The only explanation I can come up with is that you are interpreting the UI in the opposite way to me?
            I am reading it top to bottom, left to right.
            Perhaps you are reading the relationship from "right to left"?

            Mark Lassau (Inactive) added a comment - I watched the video and it displays the same behaviour as I describe above: The footer shows JIRA v5.2.6 After cloning DEMO-1, the video shows "DEMO-9 clones DEMO-1" and "DEMO-1 is cloned by DEMO-9" Which is the correct behaviour The only explanation I can come up with is that you are interpreting the UI in the opposite way to me? I am reading it top to bottom, left to right. Perhaps you are reading the relationship from "right to left"?

            Bob Swift added a comment -

            Yes, I am sure and a number of production customers have the same problem. See the video.

            Bob Swift added a comment - Yes, I am sure and a number of production customers have the same problem. See the video.

              edalgliesh Eric Dalgliesh
              farmas Federico Silva Armas [Atlassian]
              Affected customers:
              5 This affects my team
              Watchers:
              21 Start watching this issue

                Created:
                Updated:
                Resolved: