How to use script runner to automatically exalate subtasks whenever a parent is exalated.

[#1]

Given the stormy weather in Belgium today, I had some time to write up an article which I wanted to do for quite some time.

We got sometimes the question from our users how to automatically exalate all subtasks whenever an issue is being exalated

Exalate is an issue sync solution allowing to integrate between Jira, ServiceNow, SalesForce, Zendesk, ... - (and yes - I'm part of the team building that addon).

Therefore I thought to implement this requirement with ScriptRunner ...

The article shows how the exalate classes can be instantiated to trigger an exalate operation.

The way it works is

• Whenever an exalate operation is finished, a 'Exalate' issueEvent is raised
• A ScriptRunner custom listener picks up the issue event
• The custom listener will for each subtask on the issue trigger a new exalate event

Setting up the custom Listener

An image is worth 1000 words.  The event the listener needs to listen to is 'com.exalate.api.domain.trigger.EXALATED' 

How does it work in detail

The whole script code can be found on this snippet

event.issue contains the parent issue which has been exalated.  The exalateNow function is called on every subtask

The exalateNow function is a closure taking an issue object and a connection name.

• On line 26 - the connection that needs to be used to exalate the subtask is looked up, An error is raised if the name is not found
• On line 33 - an exalate issue key is generated,
• On line 36 - the outgoing sync processor is run on the subtask, creating a 'hubIssue' which is the object that will be sent over
• On line 39, the exalate operation is scheduled (internally it is called Pairing an issue)

The exalateNow code is using a couple of classes that need to be instantiated.  
This can be done using the code below

• Line 6,7 - get the exalate class loader from the PluginAccessor
• Line 9 - 13 are used to retrieve the classes from the class loader.
• Line 9 - BasicIssueKey class is used to generate a unique identifier for the issue
• Line 10 - EventSchedulerService is the exalate service responsible to manage the sync events.
• Line 11 - a twin is the couple of issues that are related to each other.  The twin trace repository contains all the twins managed by this exalate. It is not used in the code but it can be useful in certain use cases
• Line 12 - a relation is another name for connection - the relation repository contains all the defined connections
• Line 13 - the node helper class is used to run the outgoing sync processor
  
  
• Line 15-18 are used to get access to the OSGiComponents

Wrap up

This article is meant to give an example how to instantiate the exalate classes and use these to perform a more advanced synchronisation case.

Using the above logic it is possible to write a procedure to synchronise a complete issue structure (Project -> Epic -> Story) and all related subtasks.

Disclaimer

This example is using non-public api's which will change between different versions of the addon.  Take this into account whenever using the api's to implement production scripts.

The example is an example and there is no guarantee that it would work in your case.  If in doubt - there are 130+ Exalate partners providing professional services to help out. 

[francis]

The snippet has also an example of the code that can be inserted in the outgoing sync of the connection (so that it is not necessary to use a script listener)

[Moogambigai G R]

Hi @francis 

Is there any same way is possible if parent is unsynced, subtask also unsync?

Regards,

Moogambigai G R

[francis]

Yes - there is an UnexalateEvent

> scheduleUnexalateEvent(connection: IConnection, issueKey: IIssueKey)

[Andre Krueger]

Hi @francis

is there a reliable way to retrigger an existing issue sync via Java API?
We're synchronizing field values that are not directly present on the source issue, but on an issue referenced by the source issue - to populate a field on the target issue. We would like to avoid changing the source issue (e.g. by adding a comment each time the field on the referenced issue changes) to trigger the sync.

Is this possible?

Regards,
Andre

[francis]

Hi @Andre Krueger - I just bumped into your comment.

Check out folllowing snippet which allows you to trigger a sync
https://stash.idalko.com/snippets/c695ddfc49b644729f02b2041b329fb3


Important - the synctransaction will only be created if the payload changed since last sync.

To make this happen add something like

replica.foo = new Date()

Which will ensure that that condition is met.