You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
(I'm Francis - product manager for Exalate - an issue tracker synchronization solution)
More and more companies are using issue trackers to organize day to day operations. Nowadays everything is connected with everything, and the probability that you will be working with another team that is using a completely different solution grows daily.
To avoid tedious manual copying data between the different environments, different issue tracker synchronization solutions exist.
Of course - integrations can become more complex as it requires that the target Jira mirrors in some way the information of the source Jira.
Lately, we've been challenged with another synchronization case to synchronize sub-tasks which moved from one parent to another.
Assume you have the following structure (Issue Lx is synchronized to Issue Rx)
Whenever someone moves subtask LA1 to parent LB, what should happen with the twin of LA1 (RA1)? From a business point of view, you would expect that subtask RA1 moves to parent RB.
Exalate has the concept of outgoing and incoming script rules. The outgoing script rules specify what information is sent from the source to the target, and the incoming script rules define how incoming information is processed on the local issues.
These rules are specified as groovy scripts to allow for maximum flexibility. Thanks to the built-in scripting capability, almost any synchronization use case can be developed.
Additionally - on Jira Server - Exalate is running as an embedded app and is therefore fully capable to access any of the services provided by the Jira process.
Whenever a subtask is synchronized, it is important to sync the relation with the parent of the subtask
This can be done by adding the parent id of the subtask to the message that will be sent to the other side:
replica.parentId = issue.parentId
On the receiving end, it is important to ensure that the subtask parent is mapped to the right parent.
Following code-snippet allows doing so
The code snippet is also valid in case the subtask is moved from one parent to another on the source.
The message (replica) will contain the new parentId, and if the parent is found, twin subtask will be moved to the new parent.
Building real-life synchronization cases require the flexibility of a solution like Exalate. It must be able to support standard operations like moving subtasks from one parent to another and be robust enough to implement any challenging synchronization case.
Do you want to know more or a real challenge - don't hesitate to reach out here