+1

+1

+1

+1

This bug is open for more than 15 years now ...

This is a critical security issue and should be solved soon.

A global Workaround for Systems which use nginx. You can block the search and keep Users away for searching.

Add this to your Location Block:

      if ($arg_fieldName ~ "assignee" ) { return 404; }
      if ($arg_fieldName ~ "reporter" ) { return 404; }  

This is an absolut critical must-have. Our security team has disabled this functionality until Atlassian comes up with a proper solution

I see that this issue was created in 2005 and here we are 16 years later with no resolution.   

Unbelievable that this issue still exists!

The problem exists also on the Cloud version and I imagine the Data Center version also. So I don't think it will be closed forever for their discontinuation move.

Well - they did the simple thing - discontinued the product ... so these will NEVER be fixed

https://www.atlassian.com/migration/faqs#server 

@Atlassian, you wrote that you re-evaluate suggestion after a certain time. Come on and provide an update.
Your last update was in 2015!!!

O wow! So many years later and still open.
How can you effectively collaborate with multiple clients and partners in a confidential way, if such basic functionality is not taken care of?

No - I have been looking for years - and in fact, we are running multiple on-prem server instances to segregate the visibility of different customers.

Unfortunately, Atlassian has become a typical large public company focused on "growth" and not its customers. Investing in redoing core architectural issues appears to be taking a second seat to bringing to market revenue-generating "new features and products" that make them look good on the quarterly analyst calls and support the stock price, but do little for people in the trenches (like me who have been faithful customers since 2004).

Hello everyone,

like many other Atlassian users, as can be seen publicly from several forums, this feature has a special urgency for many users.
Have you heard any news lately about when and if this feature request will be implanted?
Does anyone of you know a suitable AddOn that could provide a workaround?
Thanks a lot and stay healthy!

I strongly agree.

It is a shame that Atlassian does not take care on this basic privacy issue.

BR Stefan

yes. It is ridiculous. searching for alternatives...

Jira is showings its age - 20yo architecture from the time when cyber security and privacy were not top of mind.

They have refused to address the @mention issue for years.

Our Jira implementation currently experiences the same issue.  To be specific, we are running Jira 8.5.4 Long Term Support (previously called DataCenter) with multi tenancy.  If a user is in a group with the Global Browse User Permission, that user will be able to use the @mentions feature.  If the user is adding a comment to an issue, the user will only see the other users for that issue. 

However, if the user is searching for issues and uses the Assignee field, the user now sees all users in the system

Ideally, there should be no option, no setting, no configuration that let's any user see sensitive information from users that are not in the same set of groups.

Thanks!

We (a digital agency) are facing all the same difficulties the other users stated above.

Our work-around: We removed the global "browse user" from the clients account, this works so far but has drawbacks.

Thus, they can't use the @mention-feature, for example. 

We set up a custom transistion in our workflow to give them an replacement for that... 

Then, we can't use the user-picker in our Workflows neither when customers are involved, we replaced it by simply direct assign the user to the issue.

all only work-arounds, not ideal but they work.

i would love to see that this missing feature would be adressed one time. it would make things much more easy

best,

Strongly agree - another BASIC data privacy must-have for a multi-tenant environment that is missing. Fix it please!

For people interested particularly in the @mention feature aspect of this – as per JRASERVER-69026 perhaps the mention functionality could be made available without requiring "Browse Users" global permission.

Jira already filters users that can browse the project you are mentioning on, so partners that cannot view each other's issues would not leak usernames through the mention feature.

This is a necessity in a QA environment with several clients and NDAs. This is an invaluable feature for developers working on our database, yet we are unable to provide it without exposing an important security breach. Please reconsider.

This is also an big issue for us and out customers. Please fix.

Disappointing and ridiculous..13 year old ticket not finding a way to product roadmap must be really a  trivial SECURITY ISSUE for Atlassian I guess. This is indeed a critical showstopper for business.

Please provide a fix.

Stefan, Dejan, it's probably both, (b) the core database design being very old and lacking the necessary abstractions; and (A) Atlassian has become a largely marketing driven organization, which doesn't care about companies running a single installation for a large number of projects, with separate user bases. 

Such installations are often heavily customized, so there is a big exit barrier - and what are the alternatives anyway? 

Best regards

Martin Gfeller, Swisscom

Not resolving this issue, as well as the similar @mention problem, which can be used to revela every user of the system, regardless of permissions, indicates one of two things:

A/ Atlassian's product managers do not understand the criticality of, or do not care about the impact of privacy/security issues OR

B/ THe system has core architectural deficiency preventing it from being able to address this. (8 years?!?!?)

Not sure which is worse....

I guess I'll vote for a migration instead of an upgrade when we reach our 2000 user limit next time.

We've had to restrict 'Browse Users' to just employees to prevent username leakage between customers.

An interesting side-effect is that if a customer (without 'Browse Users') uses the username syntax to refer to someone, a Mention email does not go out. It looks for all the world like a Mention, but isn't. So we've had JIRA-savvy customers typing "Hey employeename, please take a look" and ~employeename does not get notified.

It's indeed a missed chance for Atlassian. We had to reject several projects because the customer / project security and privacy  rules won't accept the visibilty of users from other projects.

With the upcomming General Data Protection Regulation in Europe,  Atlassian can expect a tough time.

12 yo ticket. Must not be enough of us that could really use this for client facing projects.

We have 2000 user tier Jira server and work on IT projects all over the world with big teams at Telco/Operators/Carriers.
We continuously have to disappoint these users because of this important and self-evident function in a team collaboration system.
I've tried several times to get any response from Atlassian on this, but may be the hundreds of disappointed teams (customers) we're working with will make them start thinking. This issue was created  more than 12 years ago! 

The only plausible explanation I can think of why Atlassian is not adding this feature is that they don't actually understand the request. It's the most obvious and seemingly easy change and it's actually what has kept us from using the product for about 90% of our projects. Most of our Healthcare, and Public Sector customers are way to paranoid to consider using a system that does not limit project view to the project users. We've been using other solutions while we wait for Atlassian to make this obvious change.

Dear Atlassian Team,

for companies with more than 1 client or 25 employees or more than one business unit project this feature can not just be a legal show stopper but is for sure a usability show stopper and is a not thought through contradiction to the project role construct. The only reason coming to my mind not to implement this feature in the near future is making the customer install and buy more instances. I would really appreciate an update on the 3 year old Atlassian comment on the 12 year old profound feature request.

Kind regards,

Hanno

Unfortunately, Jeff, for me (Cloud instance) it does it only on web. A user has told me that when using mobile app, he can @mention anyone and proved it by listing me names of people from other projects he couldn't have accessed otherwise.

There is another. troubling aspect of this. While logged in as a user confined to Project_A, on issues search screen, it is possible to type in "reporter in()". This does not autocomplete the users. If you type in a wrong username in the parentheses, it will throw back an error message at you. But if you type in a good username to a user's whose projects and issues you should have no access to, it will just say "no issues found". Since business environments usually have some code for logins (usually "name.surname"), it is trivial to find out if the Jira admin is running a project for, say, company's competition. Or anyone else the attacker find at linkedin or a similar website.

If we could go back in time, I wish Atlassian had not tied @mentions to the 'Browse Users' global permission. From a "leaking cross-project user info" perspective, @mentions are harmless. The @mentions code already checks for the project-specific 'Browse' permission (see SortedMentionableUserSearcher.java#searchForUsers()), so not at risk of leaking user details. Unlike the global user picker, @mentions always occur within the scope of a particular issue, so JIRA is able to use project-specific permissions.

Adventurous users can enable @mentions regardless of the global Browse Users permission by editing jira-components/jira-core/src/main/java/com/atlassian/jira/mention/MentionServiceImpl.java#isUserAbleToMention

@ d.schiffner1360198034 - We did move away from JSD for external Customers, this issue was the show stopper, now using Zendesk, which works great!  

However we are re-evaluating using JSD for our internal Helpdesk solution.

This is simply ridiculous... To implement such a low level of security! I just started to work with JIRA Software and Serviec desk and already looking for alternitives...  If this is not implemented ASAP we have to leave - unfortunately...

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.

Yeah, essentially what Atlassian needs to understand is, if I'm managing multiple projects, all my project users can see and assign things to any other user in any other project even if they're in other companies. This is especially bad when you end up working with very large teams and you get two people with the same name in completely different projects. 

Sometimes I wonder if Atlassian actually understands the problem or not because it is incredibly obvious that this should be the next biggest priority. 

Is it possible to continue to vote for this feature?

We have the same issue on our JIRA instance, its a no go that users from one project are able to search for users outside of their project (for example in the issue navigator searching for assignee). Please provide a solution for this, using a single JIRA instance for each project is out of the question due to administration effort

This is an absolutely critical feature for us.

We also have multiple clients in our jira install that should not be able to see each other or specific employees when for example @-commenting on issues. I realize that there is a way to limit user selection in custom fields. But there seems to be no way to limit the user list in the comment field? This will force us to disable the browse-user permission for external users, severely limiting the collaboration on large scale projects.

If this will be resolved in another ticket, please point me in the correct direction - if not, I sincerely urge you to re evaluate this request.

Huge oversight not to implement this... why would anyone want suggested users in the assignee field that aren't part of the project being viewed?

That is very disappointing. This feature seems like a no-brainer for people managing multiple teams.

Hi Ilya,

Your proposal is one way to cover the resolution, but there is not only the cases 1 project or all projects.
I had already experimented use cases where the Browsable Users were depending on more complex cases :

• Members of a Project Role in the same project or of a Group specified in the configuration of the Cutomfield (its is now covered in current JIRA version, but only for Single User field and not yet for Multi User field)
• Members of a Project Role identified by another field in the same issue
• Users identified in another Multi User Customfield
  • in the same issue
  • in a linked issue (same project or not)
• and we can imagine many other cases ...

The ideal resolution should be able to support some more generic case.
Until now, I have already implemented similar cases for my different customers, but now I am trying to finalize a more generic solution, a sort of a Polymorphic User field.
I have no ETA ... to be continue ...
V.

There could be very easy solution how to handle this requirement:
1. Add Browse Users permission to Project Permission Schema. So different users / groups / project roles could be assigned to it.
2. When loading the page for specific issue for specific project they need to check if user has this permission
a) If user has this permission then he should be able to browse ALL THE USERS WHO HAVE "Assignable User" PERMISSION FOR THE PROJECT.
b) If user don't have this permission then don't allow to browse users

Please implement it

PS. I read comments above and see problems about multiproject environment - e.g. filters.
1. Even if you forget about this case and implement this feature just for single project environment (ticket screens) you will already make thousands of people from hundreds of your clients happy.
2. If you still want to cover multiproject screens - ok, show ALL THE USERS WHO HAVE "Assignable User" PERMISSION FOR ALL THE BROWSABLE PROJECTS

PPS. If you think that "Assignable User" is not good attribute to define if user should or should not be shown then add one more attribute "Browsable User" and let us decide who can be searchable for specific projects.

I have to say that the decision not to support this is very disappointing. Is there a recommended add-on for it? It's a big privacy issue for our clients.

Michael,
If you do not mind I would like to ask a few more questions about your suggestion:
However, in an perfect world, When you create a project, you choose the group that all users will display. So that on ProjectA, only users in GroupA can be assigned to it.
As far as I can tell, you are saying that for each project you would like to nominate a set of users that will appear in the User Picker when working with that project. (As you have suggested the easiest way to nominate a set of users is by selecting a group).
The problem I see, is that the User Picker is sometimes shown in a "cross-project" context. For example, in the Issue Navigator when searching multiple projects (or all projects). So if a user is searching across multiple projects and opens a User Picker, should the user picker display the union of users from each project?
I would really like to understand your usecase. Where is the User Picker most often used, e.g. in Issue Navigator, while selecting users for a User custom field? Is the main concern security or ease of use?
If the main concern is security, I am not sure if having a project group is strict enough, as allowing a user to get access to a project will instantly grant them the ability to see the users that are linked to the project, even if the user is not a member of the group that is linked to the project.
Another thing to keep in mind is that if the Browse Project permission is given to a "Reporter", then every user will see the project. They will only be able to see the issues in that project that they have reported, but all users will know that the project is there.
In this case, I think it would be very easy to grant the Reporter permission for the project, and therefore not knowingly allow all users in the system see the users that are linked to the project.
I hope the above makes sense. I know its not straight forward, but JIRA's permissioning system is quite flexible and hence can be compliated at times. Please let me know if you would like me to explain in more details about what I mean.
Cheers,
Anton

@Anton, I think I have an easy (or at least feasible) solution to the problem: use security levels. First, let me describe what we do at our company.

Like others, we are also facing the problem of managing some customers/suppliers that we don't want to be able to see each other, and for the moment we have setup some security levels, one for each customer. Each security level can be seen by those that belong to certain groups, and only by them, and there is a separate group for each company. So if the project is called, say, TimeMachine, and our customers (or suppliers, it's the same) are from Company_A and Company_B, we have groups called TimeMachine_Company_A and TimeMachine_Company_B. The project then has security_levels like: TimeMachine_Company_A, TimeMachine_Company_B, TimeMachine_Internal. All users of Company_A are assigned to TimeMachine_Company_A, and NOT to TimeMachine_Company_B. The same goes for Company B, just reverted. Then, the security scheme works like this:

• Tickets with security level TimeMachine_Company_A can be accessed only by members of group TimeMachine_Company_A and by us (each of us belongs to a group whose members are all internal);
• Tickets with security level TimeMachine_Company_B can be accessed only by members of group TimeMachine_Company_B and by us;
• Tickets with security level TimeMachine_Internal can be accessed only by us.

This means that:

• we see everything
• Company A only sees tickets for Company A
• Company B only sees tickets for Company B

So far so good. The point is, using the Browse Users permission an employee of A could read the name (and email address, which usually contains the company name) of an employee of B, and this is what we are asking to fix. A solution would be to check the security level: the user picker should show me only users who share with me access to at least one security level, in any project. So if an employee of Company A uses the user picker, he won't see any users from Company B, because they don't have access to the same security levels. The idea is: could the 2 users ever "meet" in a ticket? If yes, the user picker should suggest each of them to the other. If not, it means they are intentionally being kept separated, and then the user picker shouldn't reveal the name of one to the other.

This idea works both when you are assigning a ticket and when you are in a cross-project contest, like the issue navigator. And it would be nice to combine this with https://jira.atlassian.com/browse/JRA-38134 (which is already fixed according to a comment, but the status is still open and I can't verify who's right because we are still on 5.2.11 here).

By doing this it would be possible to give the Browse Issue to everybody (= ease of use) while making sure there are no security concerns. What do you think?

Being able to assign client's a "Browse Users" permission that only allows them to see users on the project is very important. Currently, I am working with a client who cannot tag devs/PMs on a project because they do not have the "browse users" permission. We cannot give them the browse users permission because of the access they would have to all users, and other clients, in our JIRA instance.

This is an Enterprise issue too not just On demand. We are a large enterprise client using Jira Server and have the same problem. We don't want to keep modifying the system for things we would hope are out of the box behavior. Or at least a supported plugin recommended by Atlassian to solve it.

We are very happy in general with Atlassian but the limitations of OnDemand keep piling up.

As a contract engineering firm having 3rd parties is central. Having to have the Browse Users off is something that every customer raises, and detracts from the usability.

This is a feature we would like to see added and would use.

We love using JIRA, but this is a huge security issue for us. Please provide a fix!

This is very important for us as well. We can't be exposing our whole client list to everybody on every project.

Yes it would be nice to have our clients able to mention clients at the Project level, and not see other clients(and possible competitors).

I just discovered this "feature" as well after one of our users commented that he could see all users in the system when searching for issues using the Reporter criterion.

Just discovered this "feature". This is considered a security issue where I come from, and likely for anyone else out there dealing with more than one customer.

The fact that this Atlassian issue is ranked as a low priority "feature request" (from 2005!!), and not the critical security flaw it is in reality to its customers, pretty much says it all.

Go find someone who cares.

+1

I agree with many of the comments above. The lack of this feature is a CRITICAL hindrance to working with external developers and vendors. Please fix this soon!

Hello All,

It is certainly a good feature to have..Strange to see it's pending since 8 years. All I want is to be able to select a user from user-picker and put it in a field "Assigned By" so that I could track who assigned the issue to whom(within one particular project)

Thanks

Dear Atlassian,

I would like to request an priority upgrade. For commercial organisations this is a must have becouse this seriously limits collaborative communication.

Thanks in advance,

It is remarkable how this serious bug hasn't been fixed for years! After all it raises all kinds of privacy and security problems that has been mentioned before.

Now I myself am reporting this a critical showstopper bug in JIRA 5.2.8 - even when "Browse Users" global permission is disabled for a group it is still possible to discover other users in the system just by simple username guessing - if you guess right AJAX will bring up the user's name in all it's glory... I guess this "feature" doesn't need any comment whatsoever....

How about implementing a simple drop-down list with users assigned to a project to chose from? This can even be supported by AJAX but the user list have to be restricted to the project...

I'm in the same round like the others here, too. As an enterprise user it's vital for us, not to disclose our customers to others. This issue came up right now, because the one big car manufacturer was puzzled to see peoples working in his rival company directly in his ticket handling system.

The requirement is simple: People suggestions should be filtered down to users, who actually can see the current issue/project.

It's quite frustrating to see, that this issues is handled with the same low priority than others, which affects professional users regarding security concerns (i.e. time & efforts visibility).

While commenting on JRA-7659 I realized that this feature request is actually very important given the new "mention users" feature introduced in JIRA 5.0, which makes the default user picker even more widely used.

I repeat some of my thoughts here.

The problem has already been explained: 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.

I believe that the correct approach would be to introduce new "Browse Users" permission that limit the range of users that the user with this permission can see. This seems to be better than just changing the default behaviour.

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.

I really hope to hear your comment on this suggestion!

Hi All,

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

• 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

Hi Atlassian,

I was just checking this website of yours https://support.atlassian.com/secure/IssueNavigator.jspa?mode=show&createNew=true

The fascinating thing I found was when I selected "Specify User" from the 'Reporter' drop down I didn't get the icon (on which I usually click to get the user picker).

All I need to know how you guys are able to accomplish this. This is something that will solve my issue. If my client wants to search for issue via 'Reporter' or 'Assignee' let them enter the name rather than we giving them the user picker for them to choose.

I guess since this feature is already available in Atlassian site, it wouldn't be much problem for you guys to share the info with us.

Thanks
Jay

We suffer from the same problem.

Anton:

I would love to know if there is a much simpler more elegant solution

What about showing aonly users in the user browser that share 'browse permission' with the 'current user' for one or more projects?

If a user does not have permissions for a project why are they available in the user picker? If the user can't see the project on their dashboard list of projects, why can they be selected in the user picker?

Marko, Jarkko, Tom.

Please see the comment that Anton left in December 2007:
http://jira.atlassian.com/browse/JRA-7776?focusedCommentId=98040&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_98040

The specific comment:

"We understand that the current behaviour can create inconvenience, especially for users in larger organisations or with complex ecosystems. We are keen to attack this and we are beginning the investigation work around scoping, estimating and definition of the best solution for the feature. However realistically at this point it's unlikely to be delivered within the next 2 major releases of JIRA, which are 4.0 and 4.1."

Release 4.0 is slated for July 2009. Release 4.1 does not currently have issues assigned to it nor a target release date. The original issue is from August 2009. That will have been 4 years from the creation date of that issue and still it is not realistically going to be in 4.0 or 4.1. The facts speak.

They say they are keen to cover this. Really this is simply public relations. If you review the issues that are scheduled you will understand this type of functionality is not a priority.

Our organization has given up interest in this feature and have moved towards a better product called Target Process <http://www.targetprocess.com/>. Thankfully their support system has been more responsive to our enterprise needs.

From a developer sense you could probably write your own custom field plugin that would do this in short order. Guess these guys like to think inside the comfort box and be complacent.

Please raise priority, this is realy a blocker.

This looks logical:

• show only members of the project

This is an issue that should be fixed.

If this could be implemented this way it would be great!
User Browser shows:

• all users
• members of that project
• disabled

Alastair F, I completely agree with you.

This is a major issue, especially for us enterprise license owners and users. We cannot use the user picker because we don't want our customers to see the whole user list cause that would be a major security issue.