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

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...

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?

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...

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"?

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