How do I retrieve remote issue keys for existing already synced issues?

General Questions
, , , ,
1

Originally asked by Marianne Lee on 22 October 2021 (original question)

Hi,

I’ve gone through the KB articles How to update a local custom field with the remote issue key. However this is done during the synchronisation process and works only for the 1st sync (new issues). This does not work for issues already synced even though I did a bulk exalate.

if(firstSync){
syncHelper.syncBackAfterProcessing()
}

If I were to unexalate followed by connect, the remote issue key field will be updated but this will create duplicates in attachments and comments, hence I would not choose this option.

Is there another way to retrieve the remote issue key for existing / old issues? Eg. ability to fetch the remote issue key preferably in JQL, or using REST API or through groovy script (e.g. ScriptRuner) ?

We need to display the remote issue key in JQL search results for export and reporting purposes.

I hope there is a workaround for this, as it will be very useful.

Thanks!

2

Answer by Maximillian Thomas Nadolny on 22 October 2021

Hi Hi don’t know if I understood your question correctly, and I’m also a user but in general you can assign the remote issue key as follows.

Outgoing on the remote side (but this is in the standard script if not changed)

replica.key = issue.key

Incoming you can just do this

issue.“YourCustomField” = replica.key (for simple custom field → String)

there also is the option to do

issue.customFields.“YourCustomField” = replica.key (but doesn’t sound like you need that)

This will be executed with each sync but only be applied if there is a change if I understand correctly

If you are then using the custom field to do something else it shouldn’t be affected since there is no change

Cheers

Max

Comments:

Marianne Lee commented on 25 October 2021

Hi Max,

Thanks for your suggestion, and you’re right in that the issue.customFields.“YourCustomField” will be updated with replica.key with each sync, i.e. with each change.

This solves part of the problem. The other part getting the remote issue keys for completed/old issues which no longer get new changes. I do not want to initiate an update (add a comment, etc.) as that would modify the issue update date, which then would not be reflected correctly.

Any ideas on how to tackle that?

Thanks,

Marianne

Francis Martens (Exalate) commented on 26 October 2021

Hi Marianne Lee, Maximillian Thomas Nadolny

You are both on the right track.

The bulk exalate will only message the twins whenever the replica is changed.
If the replica is the same since previous message, nothing will happen.

By adding something like

replica.foo = new Date()

To the outgoing sync, a message will also be sent.

Knowing this you can

  • Adapt the outgoing sync
  • Perform a bulk exalate on all previously synced issues (ie by using a JQL which covers everything)
  • Remove the foo statement from the outgoing sync

Also note that if you have the connection JiraA to JIraB, and you want to have the JiraB key on the JiraA issues, you will need to adapt the outgoing sync on JiraB and run the bulk exalate on JiraB.

Give it a try and let us know

Kiet Ngo commented on 29 October 2021

Hi Francis Martens (Exalate) ,

Thanks for your response.

I have the same issue with Marianne Lee , was following this thread. I want to perform bulk exalate changes but don’t know how to get the csv file input here. I have few thousands of issues. What is the best way to do it?

Francis Martens (Exalate) commented on 29 October 2021

The screenshot you provided is of the ‘Bulk Connect’, which is a different feature than the Bulk Exalate

Check Bulk Exalate for more details