Is there a JIRA Permissions (Scheme) best Practices?

Question

I'm setting up an enterprise JIRA 7.5 instance on on-site servers (along with Confluence and Bitbucket) and doing the permissions scheme currently. I can't find any listing of "Best Practices" following the X Column of this document, but instead having the Y Column listing out things like "Project Administrator", "Developer", "Project Manager", "Super Admin", etc instead of descriptions of the name.

Does anyone have this as a resource or a recommendation scheme? My team is trying to ensure we have everything correct and are following best practices, but we're concerned because there are so many options and places to misstep.

Thank you!

jasietjx · Answer

Thank you for your reply, Joe.

That is a good idea to remove "deletion" for all users, I will suggest that to the tools admin.

Right now we are integrating users through Active Directory to link them to groups for permissions, but altering them on-site. It makes sense to only give the required permissions then; we just wanted to see if there was any official (or unofficial!) documentation for recommendations.

Nic Brough -Adaptavist- · Answer

I'm not sure what you mean by X column or Y column.

The document describes each permission in detail.  The permission scheme really is "allow person matching a rule to do this thing in my project"

The thing you really want to do is go through each line and check it's going to do what you want.  Then, the general advice, especially for new admins - use a combination of Roles, Assignee and Reporter at first.  Stay away from the other options, especially groups, until you fully understand the power of roles (although there's a good argument for possibly allowing admin rights to admins, I tend to even leave those out, so Admin really does mean just admin)

And think VERY carefully about "delete" type permissions - they really do mean delete.  The only one I usually allow is delete own worklog, and never delete issue (although I tend to allow "edit own comments" as well.

jasietjx · Answer

Hi @Peter DeWitt, thank you for your reply.

This is currently what we're in the process of doing. We have AD groups set for the different roles (PM, Dev, ProjectAdmin, Ops), and we're writing out the scheme for each role (AD/in tool). I was wondering more about suggestions for what is the smartest and safest way to go about handing out access, and if anyone had a default list.

For your AD setup, how do you use and setup the groups?

Ours currently is configured as 
Org_Role_Project

and we're using Role to describe their role and set the access rights, and Project to limit which project they have access to.