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

bob.swift@charter.net
If I follow your steps for 5.2.6, it works.
That is, I get "DEMO-7 clones DEMO-1"

If I follow your steps but use 5.2.5, it is broken.
That is, I get "DEMO-7 is cloned by DEMO-1"

Not sure why you are seeing the opposite?
Are you running each command in an empty directory?
Did you double-check the version in the footer?
Plugin-SDK has a nasty habit of ignoring the --version flag if it has already installed a JIRA - you need to use "clean" or something.

Are you guys sure something was broken in the first place? Since it appears that on 5.2.6 and 5.2.7 it is now broken with the names being reversed. Earlier 5.2.x seemed to be fine.
To reproduce:

1. New install: atlas-run-standalone --product jira --version 5.2.6
2. Add demo project
3. Clone demo-1

intersol
Firstly, for my sanity, can you confirm that you have changed the default wording of the Cloners link type?
That is, you are using something other than "clones" and "is cloned by".

Is it OK and enough to just reverse the link descriptions in admin section?

The problem with this is that you will then reverse the descriptions on all existing links of "Cloners" type.
If there are only a handful of these, then you may be ahppy to edit them manually?

My recommended approach (assuming you have non-standard names):

1. rename the existing "Cloners" link type to "Cloners (old)" or something similar
   Do not change the descriptions of the outgoing and incoming links.
   This means existing links will continue to work
2. Create a brand new Link Type called "Cloners"
   This will be used from now on by the Clone operation.
   Give it the reverse link descriptions of the old Cloners link type.

(see also https://jira.atlassian.com/browse/JRA-31645?focusedCommentId=448864&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-448864 )

Can someone provide information on how to fix this on instances that were upgraded and that do still present the bug?

Is it OK and enough to just reverse the link descriptions in admin section?

This is fixed. For a new install, it will create the clone links in the correct direction.

For existing installations, it will check the names of the incoming and outgoing clone links.
If it detects that the user has reversed the names, then it goes into "legacy mode" and continues to create reversed links.
(Unfortunately it only works for English and relies on the name being exactly "clones" or "is cloned by" case-insensitive to detect legacy mode).

fmanchon

The names of the Issue Links are not translated - they come from the definition set up by the admin in the Issue Link Type config.

I just ran into that as well on JIRA 4.4. I am trying to reword the user interface, but cannot find the appropriate strings in the usual file (WEB-INF/classes/com/atlassian/jira/web/action/JiraWebActionSupport.properties) or anywhere else.

Where would that be?

By the way, when switching from English to French, "is cloned by" remains in English

I just ran across this too. I was ready to correct someone's usage of JIRA cloning when I realized that they do not select the in or outbound term. JIRA sets this automatically. Does reversing the descriptions cause any other problems?

the more I think about it, the solution should be to reverse the link descriptions in the out of the box Jira because at this point changing the behavior of the Clone action would corrupt all the existing data for existing Jira instances.

Yes, I agree. It seems to me that the bug is that Clone action creates an outward link from the original to the copy when instead it should create an inward. I think this is a fairly egregious bug that has been around so long that everyone has forgotten about it. The work around of course is to reverse the inward and outward link descriptions for cloning. Or, the default link descriptions should be reversed out of the box for Jira.