Two way JIRA mirror

I've got a JIRA server setup with multiple projects. Some of the projects are private (internal use only) and others are public for an open source project. I was wondering if there's a way to partially mirror the server to another server. I'd need to maintain issue numbers, workflow status, etc. and it should be a 2-way mirror (most likely the public version would only be adding new issues and all other workflow would be done on the non-public server). I'd be mirror entire projects. Is there a way to do this?

2 answers

1 accepted

0 vote

Short answer is no. Mirroring would be a monumental nightmare, unless you were happy to do a lot of scripting and coding to support it.

It would be far more simple to make your Jira public, and segregate your users into

  • "anonymous" read-only access for the totally public bits
  • "external users" would get some rights when logged in and identified - adding them to projects via roles or groups, so that they can add issues.
  • "internal users" would get a lot more

That's pretty much the core of most public Jira setups. The standard permissions are designed for exactly this scenario (and much more complex ones). Even Atlassian's own site does that, albeit the model is more refined.

Ouch!

I can see why you went for a mirror idea. (Although, the little bad-hacker on my shoulder is whispering stuff about how easy it is to spoof an IP and dodge IP based security. I'll tell it to shut up)

There are some options, but they aren't going to get you even close to that sort of functionality. I'd be looking at

  1. questioning the security policy,
  2. a highly limited minimal duplication of data, with a potentially very high cost of setup and maintenance
  3. working in two Jiras with application links but no real duplication

To start on point 2, have a quick skim of a recent question which has all the links I would post if I hadn't been beaten to it: https://answers.atlassian.com/questions/96399/how-to-sync-two-different-jira-instance

That's how we have it setup now. Unfortunately our security people are changing policies. The private projects will be blocked from non-US IPs so that's severely limits access to the public projects. I was hoping to still allow core developers to do all their work on one server and still have an external server for public tracking and submisison. Sounds like that's not an option. (I also can't move the private projects to a server which isn't blocking all those IPs)

Spoofing is pretty easy but I can't expect all our users to do this just to file bugs. As for the policy, I tend to not think it's a very good one but it's one step in a number to cut back on problems from external systems. I guess they figure it's a good filter step before a more agressive (and CPU intensive) firewall ruleset..unfortunately, it's throws out mostly legitimate traffic, but it's not my policy and I don't have much say in the matter.

I'll look at #2 and see if it might be of use. I'm thinking I might be able to create a simple workflow in the public system (submitted, deferred, in-progress, closed) and use triggers on the restricted server's workflow to advance it. This wouldn't map comments, etc. but its better than nothing. Might be able to deal with manually adding the issues to the restricted server since volume isn't too high.

Yeah, I know, although we know spoofing is quite easy, it's not something you should do regularly, and it's not the right answer here. More to help yourself to a... <coughs and changes subject>. I mentioned the questions simply because the cost of working around security issues has, in the past, been a business driver for me to get the security re-examined and designed better. Always worth a try :-)

I think #2 might work, if you're happy to change your processes a bit. The closest I got was an external Jira that posted issues via email to an internal Jira. That used the basic "create or comment" stuff in a loop to update both Jiras. We then had a couple of listeners that used SOAP over SSL to update custom fields, but it was pretty basic stuff, and the external Jira was severely cut-down. Handful of projects, two custom fields and one standard config.

You can only use IP spoofing when you don't care about the response (cos you ain't getting one), so you could create tickets using the REST API, but not (in any sensible way) with the web UI.

0 vote

Short answer is no. Mirroring would be a monumental nightmare, unless you were happy to do a lot of scripting and coding to support it.

It would be far more simple to make your Jira public, and segregate your users into

  • "anonymous" read-only access for the totally public bits
  • "external users" would get some rights when logged in and identified - adding them to projects via roles or groups, so that they can add issues.
  • "internal users" would get a lot more

That's pretty much the core of most public Jira setups. The standard permissions are designed for exactly this scenario (and much more complex ones). Even Atlassian's own site does that, albeit the model is more refined.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,308 views 14 20
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
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot