Users that are not part of a security level are still potential assignees - how can I prevent this?

[Rob Horan]

I have a project whose permission scheme is based on group membership.  Two subsets of users in this group have been set up into two different groups, each associated with a security level so that only the subset can create/work on issues at their level.  The problem is even with the level set the rest of the team still show up as possible assignees.  How can I limit assignment to only those at the security level?

[David Willox]

Hi Robert,

I stumbled upon another idea today that may be just what you are seaching for.

With a user picker field (unfortunately not the app default assignee field, but any custom user picker) you can customize the possible assignees by group  using the User filtering option. For example, if I set the filtering to a Lead or manager group then only those members are selectable. I can make the selection more robust by editing the field context and allowing this field to only be used in specific issue types. This would allow you to unify all the issues under one scheme but have different assignment levels for specific issues types. The solution would be pretty intensive as you'd need to create a new assignment field for each security level, tailoring the group filtering and applicable issue types to each field, but I believe that this would accomplish what you were describing.

Let me know if this helps.

Dave

[David Willox]

Hi Robert,

Assuming that this permission scheme is specific to this project only you should be able to limit the assignable users to only the group that is intended by removing the lower security group from the "Assignable Users" permission in the Project Permission Scheme. Then, so long as your groups are set up correctly only the users with security permission can be assigned.

If these lower security users need to be assigned to items in other projects just make sure that you have a different permission scheme for your other projects where the group is allowed as "Assignable Users".

Hope this helps

Dave

[Rob Horan]

Thanks David. That's not going to work, though, since that permission scheme would affect the project as a whole.

Within the project there are 3 categories of issues:

• Issues anyone can work on
• Issues group A can work on
• Issues group B can work on

Groups A and B are subsets of the overall set of assignable users for the project.  We still need to be able to assign tickets with no security to people outside of these groups.  

Even if that weren't the case, there is no overlap between groups A and B in terms of the issue security, which means that even if I were to remove everyone else both sets of users would still appear in the list of assignable users.

This to me is a serious flaw in the design of issue security.  Someone who does not have clearance to work on an issue (as set up in an issue security scheme) should not appear as an assignee for an issue with a designated security level.  

Consider custom fields that only appear by issue type.  Let's say you made a "steps to reproduce" field for bugs and you configured your system so that the field is only applicable to bug issue types.  You wouldn't want that field to appear when creating a new feature ticket because its not appropriate.  Same here.

[David Willox]

Hi Robert,

Good point, you would need to create a separate permission scheme for each set of issue types in order for that to work, but that cannot be acheived because only one scheme can be assigned per project.

There may possibly be a way to script the user selection for assignee directly in the work item using the adaptivist script runner plugin but this will only be able to say "continue if user is part of X group", it will not prevent users from other groups being displayed and selected before the script is run on transition.

I'll get back to you if I have any further ideas but right now i'm stumped on a solution for this.

Dave

[Rob Horan]

Thanks Dave,

This is a bit absdurd/ridiculous to me as this circumvents the whole bloody point of issue level security in the first place.

[Rob Horan]

Scripting is not really an option for me at this time.  I'm not a programmer.