nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Creating sibling issues in Jira instances that cannot reach each other

Sander D

Hey,

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.

Regards,

Sander

Accepted answers

Nic Brough -Adaptavist-

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 https://confluence.atlassian.com/display/JIRA/Creating+Issues+and+Comments+from+Email for the email handler route. There's not a lot about file based text in there, but it is there.

And https://confluence.atlassian.com/display/JIRA/Jelly+Tags for the jelly stuff

All comments

Nic Brough -Adaptavist-

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.

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.

See https://confluence.atlassian.com/display/JIRA/Creating+Issues+and+Comments+from+Email for the email handler route. There's not a lot about file based text in there, but it is there.

And https://confluence.atlassian.com/display/JIRA/Jelly+Tags for the jelly stuff

AlaA

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:

https://confluence.atlassian.com/display/ATLAS/Failover+for+JIRA

Jobin Kuruvilla [Adaptavist]

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration