I would like to see this in Jira Cloud too. Missing it there.

How can I use user roles to populate issue fields?

I mean this in an automatic sort of way. Eg on issue creation, I'd like to set my SQA or Developer to the Project Role that has been configured.

I've looked in issue workflow transition post functions and custom field default values and neither support user roles.

Now that this issue added support for user roles, I'd like to use these roles in my issues to populate fields.

david.skreiner- I am currently using JIRA version 6.4.12- but I still cannot find the "User Filtering" option after creating a "User Picker (single user) field" and trying to configure it- Do you know why?

I guess, we should have something like this:

1. Have a custom field - Group picker. This should be restricted project wise.
2. Have a custom field - User picker. Based on the Group selected, User field content should change.

When can we get this feature enabled?

raju

uh thanks

The feature is there (I just found it in JIRA 6.4), but quite well-hidden. It doesn't show up when creating a new field, only when configuring an existing field.

1. Open "Custom fields"
2. Click "+Add Custom Field"
3. Create a "User Picker (single user) field.
4. After creating your field, find it on the "Custom Fields" screen, and choose "Configure" from the menu icon on the right.
You should now see a "User Filtering" option. This allows you to add a filter for project role or group.

Hi,

we have Q3/2015 and this feature still not available. Any suggestions when it will be released?

Regards,
Jan

I'm on 6.2.4 and I don't see this as an option when trying to create a custom field.

Hi Jennifer,

Thanks for the quick reply. I've confirmed with the Service Desk team that this is indeed a bug. It's being tracked in https://jira.atlassian.com/browse/JSD-590. You might want to watch it.

Cheers,

Zehua

Hi Zehua,

I am using an Atlassian Add on - Service Desk. I am trying to filter the users to pick from on the customer portal side for users to only be able to select a specific Group or Role.

I am using Jira 6.2. Thanks!

Hi Jennifer,

It sounds like a bug if you could select a user but the user is then considered as invalid when submitted. Could you try the pop up User Browser (clicking on the small icon next to the custom field with a hover title "Select a User")? Does the user in question appear in the full list of users in the pop up User Browser.

Which version of JIRA are you using? Is it OnDemand or Download?

Zehua

I have been trying to use this functionality however - When I add a filter to the Custom User Picker Field, and then test who can be selected it still pulls up ALL users instead of only those in a specific group. Any user can be selected however when I try to submit an error pops up and says "Please provide a valid selection for your ____ Field" If I select someone that I know to be in that role or AD group that I have filtered by the form will submit. From the explanation on the Configure Filter Page "Enabeling user filter will allow you to minimize the number of usernames that return from the typehead control." Have I done something wrong and missed a step or is there a bug in this release?

thanks!

aviva.zuckerman@mobileye.com, the answer depends on the type of user picker fields that you are using:

• if you use the system user pickers (for fields like reporter or assignee) the current implementation has no effect on them whatsoever; we cannot restrict the user lists for system fields
• if you have created custom user picker fields (for instance to nominate the QA engineer for a specific project) then right after the upgrade the system will become a user picker field with limited listing configurability, but it will have no limits imposed; you will need to configure the limitations for each of such fields manually; the configuration is performed per screen, so effectively this is potentially a per-project-per-issue-type configuration (depending on your setup); roles are naturally selected from the current project context, while groups are global

I hope this helps.

How will this implementation affect current user pickers? will we be able to reconfigure them per project role?

Multiple user picker extension is tracked in JRA-36833 . You might want to watch it to keep yourself updated.

Do you have any for a plugin that supports such a functionality

Do you mean releasing this as a plugin so that you don't have to upgrade JIRA to get this functionality? It's certainly possible. But it is easier to do it within JIRA at the moment.

Forget it, you are right, the custom field was not a single user picker. When you intend to extend this functionality to other user pickers? Do you have any for a plugin that supports such a functionality?

Thanks.

nikos.gretos From the screenshot, it is not clear whether "Approvers" is a single or multiple user picker? This feature currently supports only single user pickers.

Could you check whether "Approvers" is a single user picker?

Yes, I knew that but, as you can see in the screenshot, there is not such an option in the configuration page.

nikos.gretos Could you refer to https://confluence.atlassian.com/display/JIRA/Configuring+a+Custom+Field#ConfiguringaCustomField-userfiltering for the documentation on how to configure user filtering of a single user picker?

I've recently upgrade to version 6.2 but I could not find such a functionality neither for single not for multiple user picker.

Hi Bartek,
thanks for your feedback.
Frankly, I am astonished that Atlassian decided to close this issue without solving an important (I'd say the most important) part of it. Already it took you 8.5 years to tackle this. Will it take another 8 years until you start working on JRA-36896?
To all customers that voted for this issue or have commented on it: Please check the new improvement request JRA-36896 and let Atlassian know how many of us don't consider this issue resolved.

Thanks jsimon_fit.

I have created a new improvement request to track the work you suggested (JRA-36896). Feel free to comment there to provide additional feedback.

Cheers,
Bartek
JIRA Product Manager

Thanks Atlassian for addressing this.
However from what you describe, it seems you haven't really understood the user need behind this improvement request.
The main problem is that we want people to be able to use the "default" user picker, e.g. in the assignee and reporter fields and for the "mention" feature, but they should only see certain other users. So we cannot give them the global "Browse Users" permission.
If I understand correctly, your "solution" (a specific custom field type, which was already available before as a plugin) works in none of these situations. Therefore, from my point of view, this issue is in no way "resolved".
Can you explain how you intend to "cover the scenario for the user picker for system fields of reporter and assignee", which includes @mentions? Do you want to waste all the feedback collected here and wait for a new request?

I'm very keen to understand how these rules will work. For example, JIRA has no concept of a Project Team (at least for us). All JIRA Projects are open so that staff from all development teams can create, edit and comment on issues. It would be great if JIRA Projects could have project teams defined, this would assist with the rules for a user picker (i.e. the Project Team group would be available by default for the user picker of Assignee etc)

If you want limit pickable users depending depending Group, Role or by Permission, did you tried Minyaa. See in detail provided User Pickers.

If want limit pickable users depending Workflow Steps, you can also have a look on User By Workflow Step.

Else, in your development, it is better to extend the default User Picker and respect different interface for Security control (Permission and Notifications).

Hi Vincent - I am pretty new to JIRA. This ticket JRA-7569 sounds like it would resolve my issue so I wanted to vote on it.
I created a custom field called Delivery Manager and want to limit who can be picked. Then I was thinking I could just modify the notification scheme to send to User Custom Field Value. I feel my real issue is not being able to limit the list of users.

Hi Valerie,

Your customfield has to implement the interface com.atlassian.jira.notification.type.UserCFNotificationTypeAware.
Is it the case ?

Vincent

I have created a custom field to hold Delivery Manager and only want a few people available in the picker list. I have this now but no email can be sent to the person picked as its just a List of Values of names but not the real profile

We want to set a "User Picker" custom field on a new issue to default to the first person with a given role on the project. We want each issue to store this person so that it can be changed per issue, but we want it to default to a particular project role.

For example, if we have a "Lead Tester" role we want whoever has that role on a project to be the default user in a corresponding "Lead Tester" custom field on each issue.

I'm using Post-Functions in the Create transition on the workflow but I can only set the assignee to a project role, I can't set other fields to a project role.

As a clunky work-around I'm setting the assignee to the role, then copying the assignee to the custom field, and then setting assignee to reporter. This works okay but means we can't manually set the asignee field on creating a ticket, because it gets overwritten.

Unless I'm missing something. That would restrict who could be assigned an issue within a project no matter who was the one doing the assigning. For instance I'm saying it would be nice to have 20 people working in a project that my PM team can assign an issues to. However when I give my vendor an issue that they are allowed to use an assignee field where there are only 3 out of the 20 people available that they can select to assign the issue to.

howard.hammer, that is available now by restricting the users that have the Assignable User permission, which is defined on a per-project basis.

I would love a way to use the Assignee field where I could select what users are available to be selected. It would be helpful to give our vendors the ability to assign an issue to specific people they need to look at the issue while not giving the vendor the ability to assign the issue to absolutely anyone that they wanted.

I wish there was an opportunity to use a user picker in another way, just as a text field with no associations to JIRA functions. I am a big fan of abusing JIRA for other purposes, justifies my plugin addiction! (e.g. user role mgmt of an external tool)

I agree with Florin Haszler, the free User Group Picker plugin DOES most of the job !

I think there should be a check to make sure that User ID matches the person picking from the user. Otherwise I can pick any name and system does not check whether it is legitimate or not.

Sukanta Datta

Thanks for everyone's recent comments.
As we have not yet started on this feature we can not comment on how it will be implemented one way or another.
However we encourage users to continue to add their thoughts and use cases so that they can all be taken into consideration when we start to look at how we will implement this request.

Cheers,

Roy Krishna
JIRA Product Management

Without wishing to further complicate things to the point where nothing ever happens, it would be good if the user picker would optionally take into account any issue security restrictions. This would limit the picker to people who are actually allowed to browse the task.

Dear Atlassian,

a few months ago, I explained how I see the requirement of restricting the browsable users fulfilled. This is related to JRA-7467 where the suggestion is to limit the browsable users to those of projects that a user can see. This is one way of doing it, introducing more configurable "Browse Users" permissions (as suggested in my previous comment) would be another way.

I am getting back to this because I believe that this issue has become more important with the "mention users" feature introduced in JIRA 5.0. This is a really cool feature that is useless to those who don't have the "Browse Users" permission. The typical problem with the "Browse Users" permission is that we, and many others, invite external users (project partners, customers) to their JIRA projects, but cannot give them this permission, as that would disclose other customers/partners one is working with.

Of course there is definitely another use case where a user picker is limited to certain groups or roles.

As the user picker is now being used for this "mention" feature as well, I would really like to hear your opinion on this, and whether you think this can be realized.

Best regards
Jonathan

You may use the free User Group Picker plugin to solve this problem.

Have fun!

I'd also love to see the first stage of having a pick list from assignable users. The current pick from anyone in the userbase is extreme for just about any use case. This would be a minimum effort option since this code is already maintained in Jira, it just needs to be exposed.

The pick from project roles would ice the cake. This should allow selection of multiple roles, eg, Dev AND/OR QA.

FYI Our primary use case is for an issue owner - a person who has responsibility for the issue after it's been kicked around various assignees.

I fail to understand why the custom "User" field can not at least match the behavior of the built in Assignee filed. What I am seeing is that even if the user is "inactive" and does not even belong to "jira-urers" group (when using crowd) they appear in custom fields. But the Assignee field works correctly and no longer lists these inactive users.

I have to say, the really make custom users fields much harder to use for end users and it is frustrating that a fix is already working (for the build in user fields) but can not be propagated to the Custom User Field?

While you are considering to implement this feature, please do not forget the other linked issues.
I believe that the correct approach would be to have a limited "Browse Users" permission, and not only the ability to have a user picker with selected users.
I imagine something like:

• A project permission "Browse Users of This Project" that allows to browse users of that particular project
• A global permission "Browse Users of Own Projects" (i.e., all users that are part of projects that the user is also part of)

The users shown in any user picker-like (autocomplete) field would be the union of those accessible through one of these permissions and the existing global "Browse [all] Users" permission.
In addition, whether a user is shown in this list or not needs to be configurable as well.

• You should investigate whether on a global level the "JIRA Users" permission is enough to exclude unnecessary users (in combination with the above-mentioned approach) or whether you need a separate "Browsable User" permission
• At the project level, a "Browsable User" permission might also make sense

I hope that you find a way to implement this feature soon!

Would be great to have it build in!

Hi Michael,

In case of Minyaa, since theses customfield are based on UserPicker, you can update the table customfield by changing the customfield type key and the customfield searcher key.
customfieldtypekey to :

• jira.plugin.minyaa.tools:userrolespicker
• jira.plugin.minyaa.tools:userbypermissionspicker
• or jira.plugin.minyaa.tools:usergroupspicker
  and customfieldsearcherkey (for all 3 customfiedltype) to :
• jira.plugin.minyaa.tools:usergrouppickersearcher

Regards
Vincent

It is nice that there are plugins that suppurt this like:
https://plugins.atlassian.com/plugin/details/373950 (User Group Picker)
https://plugins.atlassian.com/plugin/details/8177 (Minyaa Suite)

But I have existing User Picker fields, how can I migrate them as they are heavily used? Thanks!
I also think that solving this highly voted issue would suite our needs: https://jira.atlassian.com/browse/JRA-2220 (Deactivate user)

Feedback provided by one of our customers to Support:

Yes - this is important and it is a bug, not an improvement. If the user in not in the jira-users group, they should not appear. No question.

So unless you are prepared to pay for the plugin, this does not solve our problem.

Hi All,

Minyaa 2.5 is available and provides now a set of 3 customfields in response to JRA-7659 :

• User Picker by Groups
  
• User Picker by Roles
  
• User Picker by Permissions
  

These 3 Customfields come with :

• PopUp Window for user selection
• User Search by Ajax call
• Usable in Transition
• Validation against each of their settings
• Linkifield Display
• Usable for Notification (Not yet for Scheme Permission)

Download now your free Minyaa Suite 1-month trial !
Vincent
Minyaa Suite Plugin

User picker only contains users in specified set of project roles. I'm voting for it because I need it now.

One more vote for addressing this issue. We have over 12,000 users defined in our instance (soon to be 18,000) and thus the "type-ahead" functionality is automatically turned off by JIRA for performance reasons. Therefore, having a Multi User Picker that shows ALL users and requires the user search for each one they'd like to select is a huge annoyance.

Thanks,
Betsy

response to Terry: another way to do that (which is what we use) is via the plugin "jira misc workflow extensions" https://plugins.atlassian.com/plugin/details/292 Look at the "separation of duties" condition

I would like to limit user list to all in a group except the ASSIGNEE listed for the issue. For example, I've created a custom field, VERIFIER, who I want to be someone other than the ASSIGNEE who resolved the issue to ensure independent verification.

We are looking for this exact feature. Please have it implemented soon.
/Olle

I would also like to see the Multi User Picker allow for administrators to further configure the search parameters it uses.

Jira should be returning only those accounts listed within the built-in security groups defined for any custom field, including those with permissions to view the project information - the Assignee field doesn't seem to have a problem doing that very task. Instead, all "secrets" are revealed as other accounts that are not part of the built-in groups are being returned. This definitely becomes a security related red flag.

Apparently security awareness training is a skirted topic for Atlassian?