JIRA Permissions Introduction - So Many Layers

132276.jpg

This is an introduction to a multipart series on Permissions within JIRA
One of the really cool things about JIRA is just how granular you can get with the permissions! ....and one of the more frustrating things to work through is a user's permissions issue! 


I'm here to help you make some sense of all of the permissions levels within JIRA. I'm going to start with outlining just what all of the permissions levels are and a brief description of them. I'll post some more articles about each one, going more in depth. Let's start at the top and work our way through them from Global to Issue-Level,


Global Permissions: Global Permissions are System-Wide permissions, they are independent from Project or Issue permissions. These include JIRA System Administrators and JIRA Administrators, among others that we will discuss in our next Article


Project Permissions: Project Permissions are set within the permission schemes and then assigned to a specific project. The best Permission Schemes are generic enough to be used across multiple projects. You can assign Roles, Groups, Individuals, and Issue Roles, such as Reporter, Project lead, and Assignee, to name a few. Best practices say using the Project Roles or Issue Roles are the best way to make the permission scheme simple and easy to use in multiple projects.


Project Roles: Project roles are assigned at the project level, and each role can be assigned to levels within the Permission Scheme. Individuals and Groups can be assigned to the Project Roles. Using Groups, rather than Individuals makes the assignments more dynamic. Updating the members of a Group will change the access levels within the Roles. This makes managing large installations easier.


Issue Level Security: Issue Security Level is set within the issue security schemes. Issue Level Security allows for even more granular access to a projects issues. You can assign Roles, Custom Field Values, Project Roles, and Groups. This level is helpful for a Security, Business, or HR related project. Keeping these as simple as possible allows for easier administration, and can limit impacts on system performance.

Look for more in depth articles on each one coming soon. Have Questions or Comments? Let me know and I'll do my best to answer in the comments or include it in my next article.

7 comments

Very nice synopsis...looking forward to other installments.

Does Issue Level Security override Project and/or Global.

There is no DENY, only ALLOW, so does an Issue Level ALLOW provide access to an issue not provided at either project or global level?

Kimberly Deal Community Champion Oct 03, 2018

@Mark Hudson

 

The quick answer is that It works with the Project permissions.  Example, if you want someone to be able to see something they will still have to have the project permission Browse Issues.  

This is where you might want to let a sub set of people have access to issues, such as issues only assigned to them.  

I  can go more in depth on this later this evening.

Thanks for your response Kimberly.

Certainly I can use Project Permissions for those issues assigned to them. However, I'm doing this for External Customers who need access to only those issues Labeled with their Customer name. There might be more than one Customer.

Labelling isn't currently a supported method of restricting using Issue Security, and I'm loathe to rekey the issue into a Customer-facing project either.

At this point (after 2 hrs), I've given up, and have to resort to old school report exports. Sigh.

@Mark Hudson

Yeah, you can't use lables, but you can use a group or a group custom field value (allowing you to select different groups as needed) .  So if you have the different Customers, as licensed users, and they are in groups you can set it up with that value. If there group is selected in the custom field, only users in that group will be able to see it, along with everyone else you define as being able to see it. 

By default it will deny you access (even with the browse permissions) so I guess in that way it does over ride the Project or Global permissions, so be sure to define yourself in a manner that you can see the issues, once the issue level is set. 

I have a project I set up with one security level, and all I did was define who could see the issue, because I wanted this to be applied across the board to all issue types and groups of people.  I set the issue security level as part of my create transition, so that it would just be set from the beginning and no one need to change it.  This is what my Issue Security Scheme looked like It defined all that needed to be able to see the issue.  Back story is contractors, in this not technical environment, should only be able to see work that was assigned to them.  Not anything assigned to anyone else, and only the FTEs should be able to see all work across the environment.

Issue level security.JPG

Let me know if this clears things up a bit for you, sorry I couldn't post a better explanation earlier,  was out at a fancy (IKEA) dinner. These are fiddly some what challenging to wrap one's head around and I highly recommend at least a test project, if not a test environment before assigning it to a live project. 

Also don't forget to have issue level security field available for selection on your forms, if you want more than one Security Level!

Joseph Pitt Community Champion Oct 04, 2018

This doesn't address what I see as the biggest issue with new users; JIRA, by default, gives the 'allow logon' group access to most things in the permission scheme.  This works initially until someone wants to restrict users. JIRA doesn't have a way to restrict permissions in the permission scheme. It grants access. To fix this issue they need to rework the entire permission scheme. 

Kimberly Deal Community Champion Oct 04, 2018

I think the thing to keep in mind with that is that many software and systems start out as either very open or very closed systems by default.  My experiences show that more are open than closed, out of the box, but your millage may vary.  Atlassian, as a company, actively promotes open collaboration, so it really isn't a surprise that their software would be quite open and permissive as well.  They have put a lot of thought into permission granularity over all, and while some of that may be a bit difficult to set up and understand, it is possible to control a lot of what an individual can and cannot do within their software packages.

Comment

Log in or Sign up to comment
Community showcase
Published Feb 13, 2019 in Jira

Make your Atlassian Cloud products more secure: our NEW admin security guide

Hey admins! I’m Dave, Principal Product Manager here at Atlassian working on our cloud platform and security products. Cloud security is a moving target. As you adopt more products, employees consta...

622 views 0 12
Read article

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