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; } } }

Two way JIRA mirror

Trevor Clarke

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?

Accepted answers

Nic Brough -Adaptavist-

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.

All comments

Nic Brough -Adaptavist-

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

Nic Brough -Adaptavist-

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

Nic Brough -Adaptavist-

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

questioning the security policy,
a highly limited minimal duplication of data, with a potentially very high cost of setup and maintenance
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

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

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.

Welcome!

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

Quick Links

Find more posts tagged with

jira

administration

mirror