This has been fixed in v6.0-RC1

The fix is to add a flag called jira.clone.link.legacy.direction to the advanced settings in general configuration.
When this flag is true, JIRA will continue to create clone links in the legacy reversed direction.

Upgrade tasks will try to set this flag to the appropriate setting based on the following:

• If we are upgrading from v5.2.5 or earlier then use this logic:
  • If the clone link uses the "standard" names as they appear out-of-the box ("clones" / "is cloned by"), then set the flag to false.
  • If the clone link names are reversed ("is cloned by" / "clones"), then set the flag to true.
  • If the clone link names are custom, then assume the customer set them to workaround the original bug and set the flag to true.
• If we are upgrading from v5.2.6 or higher then use this logic:
  • If the clone link uses the "standard" names as they appear out-of-the box ("clones" / "is cloned by"), then set the flag to false.
  • If the clone link names are reversed ("is cloned by" / "clones"), then set the flag to true.
  • If the clone link names are custom, then we can't know if these are leftover from before 5.2.6 or were set after. In this case we set the flag to false

So you can see that the upgrade task should ensure that the flag is set correctly for all users except those that have custom clone link names and have already upgraded to v5.2.x where x >= 6. (This includes jira.atlassian.com)
For such users, they will need to set the flag manually if they want it to be true.
OnDemand customers will need to raise a support ticket to set this flag as the advanced settings are currently only available to system admins.

Time to reconsider the fix and write an upgrade task to try and clean up existing data???

Yeah, I think so. This is confusing a lot of people.

Problem on JAC is that we don't use the "Standard" naming. We use:

Cloners 	was cloned as 	is cloned from

Whereas the code is looking for "is cloned by" or "clones" to help it figure out which direction to use.

Time to reconsider the fix and write an upgrade task to try and clean up existing data???

mlassau, do you know if the links were inverted on JAC? That could lead to Denise's observation...

I experienced this today in JAC: I cloned CONF-28277 to CONF-28334. Looks like this still affects 5.2.7 so I am reopening the ticket.

Possible workarounds for those who have changed the wording:

1)

• Change back to original wording of "clones" and "is cloned by" (reversed to preserve existing links)
  Actually you only need to set one of the descriptions like this - it will detect either

2)

• Edit the "Cloners" link type and change name to (eg) "Cloners (old)" and leave the outgoing an incoming names as is.
  This will preserve existing links
• Now create a new "Cloners" link type with your edited names in the original order (not reversed).
  New links will work correctly now.

Possible fixes if we don't like the new behaviour:
1) Revert the fix and make JIRA create Clone link types in the backwards order for new instances
2) Write an upgrade task to reverse all the existing Clone issue links and then reverse the naming.

This is an OnDemand bug so this is not the responsibility of the bug master.

This is not specific to OnDemand.

We need to verify whether the worked in OD-1 versus OD-6 statement is accurate.

Yes its accurate - please see JRA-24563 - it was fixed in v5.2.6

The old code was buggy and most people worked around this by reversing the naming on the clone issue type.
The fix is smart enough to find out if they have reversed the link names and if so, keep the legacy behaviour.
However, if the user were to use different wording (including changing to another language) and also reverse the order then they will see a change in behaviour.

We need to verify whether the worked in OD-1 versus OD-6 statement is accurate. If so then we need to fix it as part of the 6.0 effort. It should be added to the RIC backlog.

It could be a known issue. mlassau discovered it while working on RIC - it seems that there was always a bug in JIRA Clone and it used Issue Link Outward and Inward descriptions in the wrong order. So to make it working the administrator had to rename both direction to make it work correctly. I don't know if it was ever reported by someone. Mark can tell you more.

We haven't changed the Clone operation so I'm not sure why it worked in OD-1 but not in OD-6. Maybe the dump used to restore had different settings.

pslade@atlassian.com do you expect anything more from me here? How can I help?

CC fcuozzo

This is an OnDemand bug so this is not the responsibility of the bug master.

pniewiadomski can you take a look please.