• 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. 2013-03-11_0617.swf
          1.45 MB
        2. clonedby.png
          clonedby.png
          9 kB
        3. cloners-link-clones.png
          cloners-link-clones.png
          12 kB
        4. cloners-link-was-cloned-to.png
          cloners-link-was-cloned-to.png
          10 kB
        5. IncorrectWordingWhenCloning.png
          IncorrectWordingWhenCloning.png
          31 kB

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

            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.

            Mark Lassau (Inactive) added a comment - 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.

            Bob Swift added a comment - - edited

            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

            Bob Swift added a comment - - edited 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: New install: atlas-run-standalone --product jira --version 5.2.6 Add demo project 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 )

            Mark Lassau (Inactive) added a comment - 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): 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 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?

            Sorin Sbarnea added a comment - 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).

            Mark Lassau (Inactive) added a comment - 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.

            Mark Lassau (Inactive) added a comment - 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.

            François Manchon added a comment - - edited

            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

            François Manchon added a comment - - edited 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?

            Robert Poldervaart added a comment - 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.

            Jeff Kirby added a comment - 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.

            Jeff Kirby added a comment - 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.

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

                Created:
                Updated:
                Resolved: