Creating sibling issues in Jira instances that cannot reach each other


At the moment I'm looking at two Jira instances for a project that is being developed in multiple locations. These instances cannot reach or see each other. Allowing them to is sadly, out of the question.

An issue created in one instance may influence an existing issue or trigger the creation of a new one. This is up to the user who creates the issue.

I've been looking at several solutions that allow such synchronisation activities but they run on e-mail (which is not possible in this scenario) or application links. However, there is a way of tranferring files from one Jira to the other one. But it takes time. Say, half an hour for each update.

What I am looking for is some kind of synchronization procedure that can handle such a delay. I was thinking JSON or XML files that are created when triggered: "this issue influences the project on the remote Jira". Outside of the scope is the tranfer of the file(s), but on the other side a similar / part of the solution could say "I have here an issue (=XML/Json file) from the remote Jira, let's update/create issues on this Jira".

And vice versa, of course.

Googling for solutions is impossible; all syncs that are mentioned are either direct links, e-mail based or otherwise depending on a fixed and readily available transport solution.

Any ideas? I have no idea where to look for a solution.



3 answers

1 accepted

This widget could not be displayed.

Two spring to my mind. Although there's no way to avoid that delay unless you're willing to fix the cause of the delay or unblock the systems from each other.

First, you say "email is not possible", but that reminded me of something Jira can do with emails. As you've read, there's lots of stuff about "Jira 1 sends email, Jira 2 picks it up via POP or IMAP, and runs it through an email handler". What you don't see often is that Jira 2 can also read from local files as though they were email (if you've ever used certain types of local mail on a unix box, and tried looking through it's data, you'd see the emails exist as simple text files - that's what Jira can read)

Second, again based on simple text transfer, you could plonk "jelly scripts" on to the target Jira server, and configure Jira 2 to run them as a service on a regular basis.

The main difference between these two is the import code. An email solution requires an email "handler", and the basic handlers that arrive with Jira are all variations on "create or comment". The Jelly import is potentially a lot more powerful, as you can do more things with it, but you might find it harder to construct a robust and sensible system because you can do more. (Of course, you could also write a handler...)

See for the email handler route. There's not a lot about file based text in there, but it is there.

And for the jelly stuff

This widget could not be displayed.

Hi Sander,

If you require a synchronization between two JIRA instance, i'm afraid that's not really possible without having the delay. However, there are some scenarios described in the following documentation which might be helpful for such situation:

This widget could not be displayed.

If you are willing to look at a readily available solution, check out ConnectAll. But the pre-requisite is that ConnectAll should have access to both JIRA instances even if those 2 instances can't see each other.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Tuesday in Jira

What modern development practices are at the heart of how your team delivers software?

Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...

306 views 1 4
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you