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!
Comments:
Wesley Adams commented on 29 October 2021
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!
Francis Martens (Exalate) commented on 29 October 2021
You can insert the code provided in the snippet and adapt the shortnames to your case.
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?
Francis Martens (Exalate) commented on 30 October 2021
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.
Wesley Adams commented on 30 October 2021
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?
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!
Wesley Adams commented on 04 November 2021
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
}
}
Daniel Carvajal commented on 05 November 2021
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
Wesley Adams commented on 07 November 2021
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.
Answer by Francis Martens (Exalate) on 29 October 2021
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.
Francis Martens (Exalate) commented on 29 October 2021
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 …
Francis Martens (Exalate) commented on 29 October 2021
Ok adapted the snippet to take into account environments where the componentAccessor class is not available.