Two way JIRA mirror

Trevor Clarke October 14, 2012

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 votes
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 14, 2012

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.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 14, 2012

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

Trevor Clarke October 14, 2012

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)

Trevor Clarke October 14, 2012

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.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 14, 2012

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.

JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 14, 2012

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 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 14, 2012

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 Sign up to answer