JIRA Permissions Introduction - So Many Layers

[#1]

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.

[Carla Ann Rowland]

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

[Mark Hudson]

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

@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.

[Mark Hudson]

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.

[Kimberly Deal _Columbus ACE_]

@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.

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!

[Joe Pitt]

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

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.

[Alfredo Negrete]

I'm trying to create a read-only role, schema and group.  I assigned a read-only group to that read-only schema but when I associate the group to the project it gets the associated project schema assigned to the group which provides some editing functionality.  Is there a way to keep my group read only?

[Joshua Cotterell]

Is it possible to enable Issue Security to restrict Customers from opening issues, then have them submit a Confiform to edit those issues? Or will the Issue Security block them from the Edit Permission?

[Carla Ann Rowland]

Opening issues to change them is same as edit; so the rule setting will apply. Creating issue is different permission.

[Chris Holden]

Does the above only relate to company-managed projects? (team-managed being its own separate thing)

Thanks.

[Kimberly Deal _Columbus ACE_]

@Chris Holden 
I wrote this based on permissions in the Server product.  With your question about company-managed vs Team-managed, I imagine that you are using the Cloud product.  There are some differences, however, this article was written pretty general and these groupings do still exist in the Cloud product and for company-managed projects, though they are applied slightly differently than in the Server product.  There are still Global Permissions, Project Permissions, Project Roles and Issue Level Security. 

You can read more about them directly in Atlassian's Support Documentation:
Permissions:
Jira Software - https://support.atlassian.com/jira-software-cloud/docs/how-do-jira-permissions-work/
Jira Service Management - https://support.atlassian.com/jira-service-management-cloud/docs/overview-of-jira-cloud-permissions/
If you are on a Free Plan - https://support.atlassian.com/jira-cloud-administration/docs/permissions-and-issue-level-security-in-free-plans/

Project Roles:
https://support.atlassian.com/jira-cloud-administration/docs/manage-project-roles/

Hope that helps!

[Yatish Madhav]

Thanks for this article. Getting to mature our use of Jira and be more specific of how granular we can make the permissions.