nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

JIRA Bug with Group Custom Field Permission Settings

Paul Malone

We are using the Group Custom Field Permission settings for a project.

The bug is, ALL users that are NOT in the the custom field groups can still see the Project and Create Issues for the project.

Settings in Project 1:

Browse Project: has custom field with group setting

Create Issue: has custom field with group setting

Users of Project 2: Can see project 1 AND can create issues in project 1

Accepted answers

All comments

Andy Heinzer

Hi Paul,

I was able to partially reproduce this problem. In my setup I used the Group picker custom field value, and had it select a group picker custom field. I also configured that custom field to have a default value (of jira-administrators in my case).

I then added this permission to both Create issues and Browse issues. When I did this I was able to create issues in this project, but I was still not able to browse that issue when I was logged in as a user that was not in that group membership.

I found a related ticket on this in the past in https://jira.atlassian.com/browse/JRASERVER-26659

However this was ultimately closed as not a bug. While there is not an official explanation as to why on that ticket, I think I understand why this is happening better now.

Custom fields in Jira are directly tied to specific issues in Jira. There are no custom fields in direct relation to users objects or group objects. The custom field group pickers still are issue fields. So when using this specific way to set permissions for something like creating issues, there is a race condition of sorts. Since the issue has not been created yet, it cannot possibly have any value for this specific custom field. It's that custom field value that is determining who has access rights for any given permission using that attribute. I think that is why in my setup I was allowed to create the issue as a user that was not a member of that group, but as soon as I did, I was forbidden from browsing that issue because the issue now has a custom field value.

I think that is why this was thought as not being a bug.

Instead of using the Group custom field value for create and browse permissions, I think instead it would be better to simply select the permission to an explicit group. I understand that might be tedious if you have dozens of groups to add, but when adding groups this way, Jira will honor the users membership of that group. Whereas when you 're using the group custom field value, it is really only applying itself to issues that have some value in that custom field after the issue itself has already been created.

I hope this helps, please let me know if you have any questions or concerns about this.

Andy

Paul Malone

Andy,

We've reviewed internally and believe this is a bug. In fact it appears to be unusable in it's current state. Setting any permission with custom field group permission essentially breaks the project level security model.

This security approach, custom field security, is very powerful and has great potential for our use cases but it needs to do the following:

If "Browse Project" has a custom group setting. Users can view Project if:
-Member of the DEFAULT GROUP configured against the custom group field
-Member of ANY group configured against ANY issue in the project
-No other users should see Project

If "Create Issue" has a custom group setting. Users can create Issue if:
-Member of the DEFAULT GROUP configured against the custom group field
-Member of ANY group configured against ANY issue in the project
-No other users should have option to add Project Issues

ow does this sound?

Paul

PS: We are using JIRA heavily for issue tracking on major efforts. These are not software development efforts but managing large scale work efforts. We know how to do this with issue-security but this approach is much easier to understand and manage.

Andy Heinzer

Hi Paul,

Let me try to explain this another way. You can not use the 'Group custom field value' in order to set permissions on the 'create issues' option.

The reason for this is because in order to evaluate the values in the custom fields (to see if the user can create, because they belong to one of those groups), Jira has to look and see what specific value exists in that specific issue's field at that time. This doesn't make sense for the Create Issue, because how can Jira lookup an issue's value for this field when that issue has not been created yet?

In fact, it can not. Hence, that is way this does not work the way you were anticipating. Instead it appears that Jira is defaulting to allow anyone to create when use grant permission to a group custom field value.

The Group custom field value option can be useful in some other cases, such as when setting the 'Edit Issue' permission. Let's say you don't want to grant users of a group the ability to edit each issue in a project, but instead you only want them to be able to edit specific issues where this group value is defined. You could use this option in that way to restrict which issues can be edited based on a fields current value.

Does that make more sense?

Paul Malone

Andrew,

I understand the condition. The problem is the concept of having "custom field" group permissions on:

Browse Project

Create Issue

Makes no sense based on what you describe. In fact those settings don't in fact do anything other than expose the project and create issue to all JIRA users which would normally done with a standard permission.

The settings would make sense if you leveraged the logic I described; make use of the default custom field values.

Leirbag Assuab

Hi,

I must admit I'm with @Paul Malone in "Browse Project" case. Common sense appears to be as he describes.

We have a similar issue. Our scenario is slightly different. We have a Permission Scheme assigned to several projects. Our users are distributed by areas using groups that are included in project roles used in Permission Scheme to give access to projects ("Browse projects" permission). This works correctly, each user sees just their area's projects when browsing all projects.

Now, we punctually need to give to some users access to certain issues in other areas. Something like "collaborators needed to resolve this issue". So we've defined a user custom field and we've added it into "Browse projects" permission of the Permission Scheme.
Users can only see those issues where they have been included in user picker custom field. That's ok.

But users can browse all projects with the permission scheme mentioned above. We expected that users could only browse projects with some issue where user was included in user picker (plus their area's projects, of course).

Is this the expected behavior? As @Andy Heinzer says, the answer is yes. But I think there is no much common sense in this, it seems this is the way because it's the lowest effort solution in coding.

Andy Heinzer

I appreciate that there are different views about what Jira should be doing here. It feels bad to see users continue to encounter this problem. Of course you are welcome to disagree with my assessment of this problem or the expected behavior of Jira itself.

I agree that Jira has failed administrators in this regard. It's not just you, I have found a number of other reports that relate to this problem.

In my view, moving forward the best solution is to have Jira prevent administrators from trying to configure something that Jira just cannot understand. To that end I created a suggestion to implement this in

Regards,

Andy

Leirbag Assuab

I appreciate very much your quick feedback, @Andy Heinzer. Thanks!

I also appreciate your concerns about this problem and I'm partially agree with the solution you've proposed in the issues you mention (I've added a vote in those issues):

Create Issues: Ok!
Browse Projects: In my view, you can decide to show a project or not in project list by looking at values of custom fields from already created issues. If user/group appears in a issue, then its project has to appear in "Projects -> View all projects" option. Maybe the reason to not do this way is performance.

In any case, I'm completely agree in don't let to configure any option that doesn't work as it seems to mean to, or simply it not works.

Finally, you say "It causes high levels of frustration and angry users to have Jira let you do something that it has no expectation of being able to do". I didn't mean to appear to be angry or frustrated. I'm sorry if I projected that picture in my previous post.

Regards,

Leirbag.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-software