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

This feature is an absolute mandatory feature from our business perspective - surprised it's not already developed. Consider this example:

SCENARIO:

Customer A, gets added to their project and starts logging tickets for our QA review. They try to @ mention someone and get back a list of every single Jira user available across all our customers, contractors and users. This is very unprofessional and in breach of NDA's we have with clients. 

Expected Result: The Customer A, should be able to @ mention within their project and ONLY get back the users within that project as available to mention.

The mention feature is powerful and restricting it to ONLY a small subset of users within the system via the "Browse Users" Global Permission is poor decision in our view. 

You clearly have not considered all the different types of businesses and customers that use JIRA.

It shouldn't be that much development effort to create a NEW permission, that restricts the @ mention feature to only the subset of users within the Jira project you are currently viewing. The value for such a feature is much higher than the effort in our view.

Please implement!

Thanks

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.