Any progress?

Currently users from one client can see e-mail adresses from other clients which has to be restricted.

This is very much needed, I still don't understand if Atlassian understands the importance of issues raised ...also when you merged Opsgenie with JSM, Teams is not working without Browse User permission. There should not be any restriction to add users to Browse User permission to get some function to work. If we need any users to view all users, we can add to that permission but not for all users. 

Please get this feature asap.

This would be a great initiative. 

We have a field that is type "user picker / multiple users". It allows you to select Portal Only Customers. This should not be allowed as they are not users of Jira.

Hence, I vote for this change 

Thank you for the Update from October 2023 but that Article is Cloud related.
We're on Server/DataCenter and need a solution for Datacenter.

When I check the (global) Browse Users description it says

Ability to select a user or group from a popup window as well as the ability to use the 'share' issues feature.

So IF I'd restrict the browse users function, then our technicians can NOT share the ticket with their colleagues. If I do no restriction the technicians can also mention and share to developers, which they should not.

We need the ability to restrict "Browse Users" not only for groups but also for purpose.
I as Agent do require the ability to mention and share to everyone.
Reporter, however, should only share and mention between Reporters, maybe Agents, too, but Certainly no Developers
Developers also should be able to share and mention other Developers, but they also should not have contact to the Reporter directly.

BR
Christian

PS: @Atlassian: please do not forget DataCenter. We pay a FORTUNE for your licenses and it s***s that only Cloud is developed further. I understand your strategy to push cloud, but then LOWER the License Cost for DataCenter!!
PPS: I know the request is only 10 years old and Atlassian only considers tickets which are at least 15 years old. But maybe you can make an exception?

This is crucial for security purposes. Please provide us with a resolution.

The watchers of this ticket may be interested in this post: Improvements to Browser User permissions (User Searchability by Project). Please add any questions or comments there.

Any updates on this please?

Does anyone know if this relatively new announcement will help correct this annoyance or is it unrelated?
https://community.atlassian.com/t5/Jira-Service-Management-articles/A-dedicated-product-access-role-for-internal-customers-in-Jira/ba-p/2279244#M2631

Absolutely need this to support some of our workflows. We plan on implementing a single customer-facing project since it needs to interface with other internal Jira Product Discovery and Software projects. Having customers appear in our user pickers is not okay. 

Another use case: filter out customers (from a Service Project) that are not "users" (not listed under Admin User Management).

This is great to see that this issue is being noticed. Flexibility is good, but not to this level which has always concerned me.

This really is needed as a useful feature but ultimately will help the performance of the reporter/customer lookup. This query is pulling back way more data than it needs to, which is exponential against all tenants. 

Hi Atlassian Team 

Many thanks for considering this request. Has the assigee users restriction now been implemented ? Any ETA when it is going to be live ? 

This is critical. how is this not supported?

Hey a0498880b5dd thanks so much for identifying those duplicate issues. I am going to ask if their watchers would be ok with closing them in favour of this one so that we don't dilute votes.

Dear Atlassians,

with all due respect to you and your amazing work, from our point of view this should not be a mere feature request. It should be reconsidered as a big bug.

There are many similar reported issues (probably causing a fragmentation of votes) which proves in a way how big privacy concern it is.

• Suggestion: Don't show users (or Portal Only Customer) who doesn't have Jira application access to appear on reporters and project roles list (59 votes)
  https://jira.atlassian.com/browse/JSDCLOUD-10055
  Created 10/Mar/2011 2:03 PM

• • It is creating panic among our teams that clients visible in the Reporter field and if selected may provide clients access to our internal discussions, work, etc.

• Suggestion: Limit User Picker to members of certain groups/roles in System Fields (312 votes)
  https://jira.atlassian.com/browse/JRACLOUD-36896
  Created 07/Feb/2014 1:55 AM (related JRASERVER-7659: 16/Aug/2005 4:13 PM)

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

• • It is a big issue and seems like a problem for GDPR that even if you don't have access to another Jira project you can see that project's customer's personal information (name and email address).

• Suggestion: Restrict Reporter Field to only users with Create Issues Permission (51 votes)
  https://jira.atlassian.com/browse/JRACLOUD-42446
  Created: 13/Mar/2015 1:38 PM

• • Dangerous - it breaches privacy where issue content is shared in an email notification to the new "reporter"

• • Confusing - the new "reporter" doesn't understand the reference/relevance to their product support

• • Time wasting

1. 1. 1. the "reporter" wastes their time in alerting us of the error in selecting the wrong reporter, and

1. 1. 1. it wastes our time to understand what has happened and how to appropriately resolve the reporter used in error, and

1. 1. 1. it delays the issue resolution if the SD Team member is trying to get further information from who they assume is the intended reporter to fix the issue. *Especially if the issue is a P1 or P2 these delays could be very bad.

• Bug: Customer without permission to project can be added as a reporter of a request (7 affected)
  https://jira.atlassian.com/browse/JSDCLOUD-8649
  Created 28/Nov/2019 12:27 PM (probably much more earlier according to issuekey)

• • Exposes customer contacts to any Jira user on the system.

• • External customers could be accidentally associated with others tickets not remotely related to theirs

• Suggestion: Customers shouldn't be suggested on User Picker custom fields on non-Jira Service Management projects (19 votes)
  https://jira.atlassian.com/browse/JRACLOUD-76780
  Created 07/Jun/2021 4:08 PM

Maybe more.

This is critical due to security reason. Please enable it in cloud Jira asap.

+1 really needed!

This is core functionality in Jira Server that needs to be present in Cloud for migrations, I find it troublesome that this has been open for so many years with little to no movement from Atlassian. If you're expecting Cloud migrations to happen then support them, don't hinder our progress. 

^Oh, well I dont have permission to attach images in this issue, I wish I could so I could show you, and I also wish I had permison to block those many random options from even showing up!

On my reporter list its quite annoying that I have to choose between the apps on my site which would never be the reporter. In my case we adjust the reporter in our Software Development page. Only the developers have access to transition edit and update issues in the project however they label the reporter as the original team member to find the problem who knows most about it. But its very annoying to have to chose from options which have no reason to be in there in the first place. Please fix and look at attached image for example! 

Wholly agree. Right now non-employee users in our Jira Service Management appear everywhere also. This is ridiculous given that there are thousands of folks in that list.

We are trying to migrate to Jira Cloud. In several of our Jira Server projects we have customuser picker fields that are limited to certain defined users in a group, ie Project Developer Resources and Project QA Resources.

In re-implementing the custom field as a user picker in Jira Cloud the limit appears to be only a filtering suggestion in Jira Cloud ->Enabling user filtering will allow you to minimize the number of usernames that return from the typeahead control. It is not a hard limit and allows non group members to be selected. This is not acceptable. This needs to limit selection to ONLY members of the filter group. 

Is there any progress toward provided a forced limit on a user picker? The ability to make an incorrect selection will not go over well with Project Managers. 

Any updates on this??

Any updates on this? 

Any updates on this? 
 
 

Any update on this?

Any updates on this? 

In the face of the GDPR, it should be only a matter of time until Atlassian will be sued for this issue in their cloud hosted environment. After all, they are data processors so any unwanted disclosure of personal information will lead to a breach of the GDPR. It's simply an inconceivable flaw in the system and not even one that would be hard to fix.

I wonder how much more interest Atlassian wants to gather until realising that they're exposing themselves to serious damage claims in EU.

Checking in again since it's been a year since all of the watchers were pinged on this one (apologies).  Anyone have any way to limit the Reporter on a project basis for Jira Service Desk?

It is a big issue and seems like a problem for GDPR that even if you don't have access to another Jira project you can see that project's customer's personal information (name and email address).  We don't want to stop showing email address in the search, but instead only show the customers that are in the project.  Maybe there could be a way to add a "Users who can be Reporter" permission in the permission schemes like "Assignable User" or a way to toggle the global permission of "Browse users and groups" on a project level instead of system (maybe add to permission schemes again).

I find it funny that people complain all day long about wanting to change their domain name (which is nice that they are implementing, but not really a bug) and things like this go undetected by the masses.

We created a group and added it to the 'Assignable Users' permission on the project. Not ideal, but it does limit that list to those people.

Atlassian - any updates on this? Michael Dennis summed it up very well in his last comment. My JIRA users are also confused/annoyed/frustrated by customers showing up in the list when they use the user mention feature. JSD customers don't have access to JIRA software and it makes no sense why they would appear as users anywhere in JIRA.

Thanks!

I have used the "Assignable User" permission to restrict, but I still have the following results:
1. Assignee – Workaround using “Assignable Users”
2. Reporter – The list of ALL Portal users are still visible.
3. @Mentions in Comments and other fields - The list of ALL Portal users are still visible. This could be prevented by changing the field type to NOT be a wiki style renderer, which would mean losing the ability to (among other things) not have images. Which we cannot do.
4. Watchers – The list of ALL Portal users are still visible.

There needs to be a method either global or individually for each of these fields and the @Mention feature to restrict the Portal Users in JSD from showing up in Jira.  For me I'd be happy with this being done on a Project basis, but that may not meet others usage requirements.

It is very shocking that this is not already able to be done. JIRA and JSD are essentially the same "system", I get that it might work this way by default.  But and a big one - Anyone using JSD to support Customers and especially those like us trying to support external Customers would never want the JSD Customers showing up ANYWHERE in Jira.

Thanks,

Michael

Michael, concerning your request feature 1, you can do it using role instead of group in the "assisgnable user" permission. Roles members are defined by project.

But it won't solve the @mention problem.

The permission for "assignable user" also does NOT restrict what users can be seen when using the @mention feature.  Though it seems like it should.

This is a serious limitation as we heavily rely on @Mentions in our Comments, seeing the thousands of customers in that list and having the possibility that they could be emailed as a result of a mistaken click would be a show stopper and cause us to abandon JSD!

JRA-36896

I’ve worked through what will have to be a good enough solution to this for now.  Sharing so that others may be able to take advantage of this and to ask for two additional features.

To elaborate on our environment some and then offer a potential work-around that I believe works.  We are currently trying it out and so far all is good.

We are using Jira and Jira Service Desk (JSD) Cloud – we have two projects: 1) Jira = “Project X” and 2) JSD = “Project Z”

ALL “Customers” in JSD are ALSO automatically in the Jira Users list.

These two things meant that while in Jira, the System fields of “Assignee” and “Reporter” would also display the complete list of ALL of our Customers and allow them to be Assigned Issues or be able to be made the Reporter in Jira.  Something that we simply can NOT have, period.

I got a hint of a possibility while looking through the related Issues, in particular JRA-7776. I started looking at Permissions to handle this issue.  I found “Assignable User”.  This looked somewhat promising. So in the Permissions Schema for the Jira Project X, I changed the Assignable User permission to just the Group “jira-software-users”.  This could be any group that has the users you want.  The consequence is that none of the JSD “users” (really our Customers) in JSD Project Z can be assigned an Issue in the Jira Project X AND they no longer show up in the list.

Feature Request 1 - It is unfortunate that this Permission (Assignable User) and others as well can NOT be granted to a “Project”, as this would be preferred and would restrict the Assignable User even further to just the Project(s) that are needed.  But for us, for now, the group solves our immediate need.

Feature Request 2 - Unfortunately there is no comparable permission for “Reporter” something like “Assignable Reporter”, as I would much prefer allowing some on my team to change this so that they can Report an Issue on behalf of another, but only another Jira user (or a specific group) and again preferably in the same project.  Because this does not exist I cannot allow anyone other than myself (the project owner) to change this field.

I hope that this helps others and that the Feature Request gets created.

The ticket was logged 07/Feb/2014, so a solution can come any minute now...

We are using JIRA and JIRA Service Desk (JSD) Cloud - It is simply amazing that this works the way it currently does.  Flat out busted.  Especially when you also are using JSD as ALL of the customers (we have thousands) are showing up in Jira.

This is simply a MUST fix or we will be forced to abandon JSD.

I do not see the "user filter" when I create a custom field. Configure page does not show the option there and my version is v6.4.5

We discussed this internally, there's no real option for us to offer the same functionality on cloud anytime soon.

Not for those of us on Cloud though :-/

Problem solved: https://goo.gl/TYc2OR

You may

1. create User Picket Custom Fields to let the user select from your preferred group or role and then
2. let the system field take that value in the transition's post function.

This is what we have done long before (since JIRA 4) these settings were available in JIRA using (part 1) one of our pickers (User Group Picker now retired because of the almost complete overlap with the new JIRA User Pickers, or the more advanced programmable User Group Picker PRO (that lets you mix groups, roles with hard coded users) and then (part 2) copy the value in the post function using JJupin with a line of code (like assignee=userpicker).

Please note that there are also other options to copy values between fields.

HTH,
Florin Haszler

How about "sharing a issue" function?
https://confluence.atlassian.com/display/JIRA/Emailing+an+Issue

Hi davidrr,

The feature for watchers is JRA-7776 and I have linked it to this issue.

Cheers,
Danilo

I hope watchers is also something you're covering.

Agree with you Jonathan
I believe this paragraph from your comment might be the heart of the requirement:

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.

These comments originate from JRA-7659 because the solution for that issue does not solve the main problem I described there, as it does not work on system fields or the @mention feature, which rely on the global "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.

One way to solve this would be to restrict the list of users based on existing permissions/roles (JRA-7467 is about this). However, 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 an advanced implementation, exclusion of certain users would also be desirable (not only for former employees, see JRA-11156--this has been solved with the account disabling feature):

• 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!