Link Issue to Existing Remote Issue via Visual Mode

 
1
0
-1

Hi,


I need each issue on my local instance (Jira Cloud) to be linked to an already existing issue on the remote side (Jira Data Center) with the same issue key. I am using a Visual Mode connection and need this to be done via a script under the connection rules as I need every issue that is exalated to follow this process. I have pre-created all necessary issues on the remote side and this is necessary due to our code (Fisheye) being managed in Jira via issue key. 


I found the helpful code below from feedback on this page provided by Francis Martens (Exalate) .


if (firstSync) {
   issue.id = <fetch the appropriate target issue id>
}


It is mentioned that the code should be added to the incoming sync and that the process for fetching the target issue id depends on the environment. 


Since the scripts for the Visual Mode connection are applied on both sides, what adjustments need to be made to this code for it to create the same result from a visual mode script? How would I also fetch the issue ID in this particular environment (Jira to Jira)? Any help would be much appreciated! 

  1. Wesley Adams

    Hi Francis Martens (Exalate) , thanks for the quick response. I am not sure I understand the applicability to the visual mode where both sides are handled in the same script.


    I am looking for code in the same format as the examples provided for visual mode scripts with your_instance_shortname format. I am not very familiar with groovy scripts but want to use your product in this way. Can you provide the example code in this format so that myself and others who need to use visual mode and match issue keys in this way can have the code to do so? Thanks!

  2. Francis Martens (Exalate)

    You can insert the code provided in the snippet and adapt the shortnames to your case.

CommentAdd your comment...

2 answers

  1.  
    1
    0
    -1

    Thanks Francis Martens (Exalate) , I look forward to testing the code out for issue key matching that you have provided here. Could you speak to what I would replace "AN-483" with in the code below? Or would I leave that in regardless of my environment? 

    def twinIssue = issueManager.getIssueByCurrentKey("AN-483")
    1. Francis Martens (Exalate)

      I had to test out with a fixed placeholder.

      The "AN-483" needs to be replaced with the issue key that you would like to  look-up.

    2. Wesley Adams

      I am not sure I understand what AN-483 would be replaced with if this code is meant to be entered as a script on the visual mode for the entire instance and guide behavior for any exalated issues instead of a single application. I was under the impression that I could adapt the shortnames to my case and it would work as mentioned earlier. Would the below code work in its place? Could you update the code so that it would work across the instance in visual mode connection as requested? 

      def twinIssue = issueManager.getIssueByCurrentKey(localinstance.issue.parentId)
    3. Francis Martens (Exalate)

      getIssueByCurrentKey is expecting a key and not a parentId

      I have no idea what the shortnames are but I would expect something like 

      def twinIssue = issueManager.getIssueByCurrentKey(source.issue.key)


      Give it a try.  
      You can always see what is going on with the debug.error


      debug.error("twinIssue = ${twinIssue}, source issue key = ${source.issue.key}")
    4. Wesley Adams

      Thanks for providing that feedback! parentId was a typo as I intended to replace it with key. I will try this out and let you know if I have any issues! 

    5. Wesley Adams

      Francis Martens (Exalate) I input the suggested code above with the alterations and it did not work. Please find my code below. For context the short name for our cloud (source) instance is "Cloud" and the short name for our Data Center (receiving instance) is "DC"


      if (firstSync && executionInstanceName == "DC") {
    
    try {
        def ComponentAccessorClass = "com.atlassian.jira.component.ComponentAccessor" as Class
        
        
        /* assume that the target issue already exists on the local tracker (jira DC)
       ** look up the issue, and extract the id
       ** make sure that the source contains the key
       */
       
        def issueManager = ComponentAccessor.getIssueManager()
        def twinIssue = issueManager.getIssueByCurrentKey(Cloud.issue.key)
        if (!twinIssue) {
           /* when the twinIssue is not found, ignore the sync.
           ** Alternative is to raise an error using throw new IssueTrackerException like in
           **
           ** throw new IssueTrackerException("Issue with key '${replica.key}' was not found")
           **
           */
           
           return
        }
        
        DC.id = twinIssue.id
    } catch (Exception e) {
        // ignore the fact that the componentAccessor cannot be accessed, which can happen on non Jira On premise
    }
   
}
    6. Daniel Carvajal

      Hi Wesley Adams 

      Can you elaborate on how it didn’t work? (did you receive any error or script notification? If there was maybe the error stack trace would shed some light into what happened).

      Cheers,

      Daniel


    7. Wesley Adams

      Daniel Carvajal I do not get any error messages or notifications. The sync simply creates a new issue to associate with the one that was exalated instead of matching it with the issue that has the same issue key on the other side. 

    CommentAdd your comment...
  2.  
    1
    0
    -1

    So the lookup should happen on the Jira DC side.
    The approach is then pretty straightforward as you can rely on the issueManager to return the local issue object.


    Code example detailed in Look up issueid using an existing issue key 


    Hope it helps

    1. Francis Martens (Exalate)

      Since the scripts for the Visual Mode connection are applied on both sides, what adjustments need to be made to this code for it to create the same result from a visual mode script? How would I also fetch the issue ID in this particular environment (Jira to Jira)? 


      I missed this in highlighting the approach.  Of course the import statement will fail with JC inbound messages ..


    2. Francis Martens (Exalate)

      Ok adapted the snippet to take into account environments where the componentAccessor class is not available.

    3. Wesley Adams

      Serhiy Onyshchenko , would you mind taking a stab at this one given your successful script for  the somewhat related issue of syncing epic links?

    CommentAdd your comment...