Managing Project Permissions via Custom Fields

[Victor]

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?

[Joe Pitt]

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.

[Nic Brough -Adaptavist-]

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.

[Victor]

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?

[Nic Brough -Adaptavist-]

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

[Radek Janata]

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!