Managing Project Permissions via Custom Fields

In Permissions Scheme, it's possible to set up a permission based on user picker or group picker custom field. I do understand how it works in case of Issue Permissions. But what about Project Permissions like Administer Projects, Browse Projects? Does it mean that a user or group mentioned in any of issues with a given type of the custom field will get a corresponding permission of the project?

1 answer

1 vote
Joseph Pitt Community Champion Oct 07, 2015

Each activity, such as administer, browse, create, and etc. have their own permission list. So a user from the picker list could have browse, but not create. The problem you may get into is the user may be in multiple groups and may gain access you didn't intend.

Also be aware that you may grant more than you think by accident. The really obvious example is that if you grant "browse" to "reporter", most people would think "well, that person can only see issues they reported". Nope. A person with "create issue" doesn't even have to be named as a reporter on any issue and they can see the entire project. This is because it's a *project* permission so it really does mean "all issues", and they *might* be a reporter. For that reason, I tend to avoid using user/group pickers in project permission.

Joe, Nic, thanks for the reply. I'm afraid I didn't get the idea of how permissions like Administer Projects, Browse Projects work in this case. How does a such permission relate to a custom field of a particular issue?

Some types of custom field hold users (i.e. references to specific user accounts in JIRA, rather than text, numbers, options or dates). JIRA can use users and lists of users in permission schemes. An obvious instinctive use is that you can say things like "this user can edit issues" or "this group of people can edit issues", but the use of custom fields translates so you can say "the user named in this field can edit issues" or "the people named in this multi-select can edit issues" The problem with using custom fields like that is that permissions are *project* wide. So if you name a person in a custom field used in a permission scheme in a single issue, then you give them the *project* permission to do something. So you need to be a bit careful with it - if you name a user field in the admin permission for example, you could give every user in your system project admin rights...

Let me refresh this discussion as I have been dealing it this now.

This seems to be true only partially. 

If a user is added to a specific user-picker custom field and this custom field is granted Browse Project permission, then the user is able to see only this single issue.

However, as Nic mentioned it is Project permission so the whole project is now accessible to the user - the user can then see project components, versions, boards etc. But the user can see only the issues where this user is put into that user-picker custom field.

So, be aware of this!

Suggest an answer

Log in or Sign up to answer
Community showcase
Asked Thursday in Jira Ops

I'm John Allspaw, Ask Me Anything about incident analysis and postmortems

I'm John Allspaw, co-founder of   Adaptive Capacity Labs, where we help teams use their incidents to learn and improve. We bring research-driven methods and approaches to drive effective inciden...

5,333 views 21 17
View question

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