What's the best way to manage permissions between Dev and Prod JIRA environments?

We're trying to figure out governance guidelines for my client in JIRA. They've purchased the tool and a bunch of licenses, but are currently light on support funding. In the future, we might have a dedicated JIRA admin who also manages the governance, but right now we're looking for a solution that assumes less-experienced admin support. The original support model assumed a small support team with Global Admin rights, but they're realizing that the features and customizations that our users want are much greater than they anticipated. However, there's still some resistance to giving Global Admin rights to all our PMs. 

My idea is to implement a three-environment model (DEV, TEST, PROD), where we give Global Admin rights to our PMs in the DEV environment, but only Project Admin rights in TEST and PROD. This way, they'll be able to play around in DEV and create any new Issues/Workflows/etc. they want, and then request that their creation be migrated into TEST and PROD by the JIRA Admins (who will have Global Admin rights in all three environments). We'll be able to have our PMs learn the tool and do most of the actual work in creating what they want in the tool, which takes a lot of work out of the hands of the JIRA Admins. I'm trying to figure out if this three-environment model will work, and if we can split up the permissions this way or if it'll run into trouble. 

This question sounds similar to mine, though it is four years old:

https://answers.atlassian.com/questions/24527

2 answers

Hi Tom,

Recently we published a blog post describing a way to solve this problem that is very similar to your idea and also makes the migration of changes between systems automatic - http://www.botronsoft.com/2016/03/29/how-to-deal-with-the-jira-administrator-bottleneck/

Feedback is welcome smile

Thanks!

1 vote
Joe Pitt Community Champion May 20, 2016

If you are going to use the same screens, workflows, custom field, etc. between projects (one of JIRA's big advantages) you can expect problems with people stepping on each other and creating duplicate fields. One of the Admin's jobs should be reviewing requests and making sure duplicate fields aren't created and any change in workflows is OK with everyone using it. Moving components between JIRA instances can be difficult. As such I don't recommend the process you're proposing.Instead, if they want to experiment download one of the $10 limited user license copies to their machine for them to play with. If they design something they like it can be documented and rebuilt in the real system.

Moving components: https://answers.atlassian.com/questions/234266

Suggest an answer

Log in or Sign up to answer
Atlassian Community Anniversary

Happy Anniversary, Atlassian Community!

This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.

Read more
Community showcase
Julia Dillon
Posted Tuesday in Jira

Tell us how your team runs on Jira!

Hey Atlassian Community! Today we are launching a bunch of customer stories about the amazing work teams, like Dropbox and Twilio, are doing with Jira. You can check out the stories here. The thi...

141 views 1 17
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