Is there a JIRA Permissions (Scheme) best Practices?

[jasietjx]

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!

[Peter DeWitt]

@jasietjx, I would say it depends on where your users are located.  For example, I like to tie all my users & groups back to Active Directory so I create custom permissions schemes that utilize AD groups as well as the few basic Jira groups.  

If you want you project leads or admins to manage project access try utilizing the project roles more.

Overall, I would recommend standardizing the security groups as much as possible across your projects. 

.pd

[jasietjx]

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. 

[Joe Pitt]

I would say you just need to follow the industry best practice of only giving required permission. the FIRST thing you need to do is delete ANY group that has logon/application access permission from the scheme. JIRA gives them that by default.  I suggest you use project roles to give permissions. It can be pretty granular and the project lead can manage permissions, where as groups require JIRA admins to add/delete members from groups. 

I also suggest NO ONE have permission to delete issues.  Deleting issues with bite you sooner or later. There are tons of people in the forum looking for a way to restore deleted issues. Basically you can't.  I use a resolution of Deleted to indicate issues that are no longer needed. 

[jasietjx]

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-]

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.