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

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

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.

It seems that Atlassian does not give this issue a very high priority as per the comment listed here by Anton:

Hi Alastair,

We are not able to provide a concrete time line, as this very heavily depends on how long it will take to deliver the features that are being developed and investigated for the next 2 major releases. However, I feel that this is very unlikely to happen sooner than 12 months.

There are a number of other issues that are related to this issue, however, when scheduling them, we have to take into account all of the currently open requests.

Cheers,
Anton

(see http://jira.atlassian.com/browse/JRA-7776?focusedCommentId=98409#action_98409)

Also note that I had previously added comments to that issue regarding the difference between "Enterprise level" and "mom-and-pop shop" problems, with this problem being an Enterprise level problem. I had made the criticism that some of the folks at Atlassian don't seem to want to address Enterprise level problems and prefer to stick to the smaller problems, forcing large companies to find other solutions. Our company has 3 enterprise licenses but our enterprise needs don't seem to get met.

You could read this criticism yourself except for the fact that someone saw fit to delete it.

Some of our customers have also expressed security concerns with the user browser. They don't want a user of one project to be able to see users of other projects in JIRA. Perhaps this can be a JIRA administrator configurable setting as below?

User Browser shows:

• all users
• members of that project
• disabled

Hi,
I've ran into this problem as well. We have multiple external clients who access our JIRA instance, and the User Picker reveals all users, which is not desirable for all the reasons stated above. There needs to be a way to associate users with projects (or through groups that are associated with such projects), so that when a user operates the User Picker, that user only sees people from projects he/she has permission to see normally. I do not believe this needs the creation of a new admin. It should work the same way when a user tries to assign an issue: in that scenario, the user only sees people on projects he/she is normally able to view.

I will explain a little about what I am doing and then give the answers to your questions.

We do medical research, so each "project" is a study, our end-users, send jira email with issues that happen over the course of a study. An end-user may be part of more then one study(project) on our system. Staff members as assigned to a study(project) and have to only be able to see users in that study/project. (An end-user might be on studyA,StudyB, and studyC but a staff member for studyA should only know about that user from studyA)

To answer your questions,

When you hit the userpicker from a project page, it should give you a list of all the users for that project.

If you hit it from else where, it should give you a list of all the users you are allowed to see no matter what project they are on (It would be GREAT if you could filter by project when hitting it from a non-project page)

Jira is an AWESOME piece of software, but we could get in a lot of trouble if we use it as is.

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

Michael,

Thanks for your feedback.

Neal,

Thanks for letting us know. Do you have a solution that will work for your use case?

Another thing to keep in mind is that we are trying to get away from using groups as much as possible. Groups are being replaced by Project Roles where possible. At the moment, I am not very clear how this feature will overlap with Project Roles.

Cheers,
Anton

For me, I would only want my users to see users in groups they are a member of.

So, If I have ProjectA,ProjectB,ProjectC, and GroupA, GroupB,GroupC. You would only be able to see members of the group(s) you are in.

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.

Does this make sense, this issue, is the only thing preventing me from buying JIRA.

Michael

only showing users that are members of the same groups as the user to whom the User Picker is being shown.

Just to add my use case - my external clients are all in one group. I surely don't want them to be able to see all my clients!

Andrew,

Thanks for your feedback.

This list contains the users I want to be able to see in the user picker with the exception that it should also include users who aren't "assignable users".

This is the exact source of the problem. How do we actually work out what users to show in the User Picker?

This is why I started talking about only showing users that are members of the same groups as the user to whom the User Picker is being shown.

Josh,

I think this is the way to go including excluding the "global" group (most cases jira-users). You can have a section in the admin where you can specify what group is the global group so no matter the name, it always excluded from the picker.

I do not think there is a need for another admin section. We can already work out what the group is by checking which groups are given the global JIRA Users permission. For more information on global permisions please see JIRA on-line documentation:
http://www.atlassian.com/software/jira/docs/latest/global_permissions.html

If they system is only used internally, you can have a checkbox that says, allows all users to see all users or something like that.

If the system is deployed internally and externally, couldn't this be accomplished by creating an internal 'global' group called "atlassian-staff" or similar so that if I belong to Atlassian staff, I can see all Atlassian staff? So it would work within the frame work you specified, it would just require the admin to setup a second or third 'global' type group for internal users.

I was planning to solve this problem by intorudcing another global permission called Browse All Users. This global permission can be given to one or multiple groups. Members of these groups will be able to see all user accounts in JIRA.

Does this make sense?

All of this still seems a bit too complicated for me. I would love to know if anyone can see a more elegant solution.

So please do not hesitate to let me know what you think.

Cheers,
Anton

Hi Anton,

One way to go about this issue is to only show users that are members of the user's groups in the User Picker. The problem is that a user has to be part of the group which is given the global JIRA Users permission (in most cases the jira-users group). As all users have to be part of this group this prevents us from solving the problem.

I think this is the way to go including excluding the "global" group (most cases jira-users). You can have a section in the admin where you can specify what group is the global group so no matter the name, it always excluded from the picker.

If they system is only used internally, you can have a checkbox that says, allows all users to see all users or something like that.

If the system is deployed internally and externally, couldn't this be accomplished by creating an internal 'global' group called "atlassian-staff" or similar so that if I belong to Atlassian staff, I can see all Atlassian staff? So it would work within the frame work you specified, it would just require the admin to setup a second or third 'global' type group for internal users.

Regards,

Josh

Hi Anton,

I'm not sure about this "Company" concept, that could be something entirely different or just means "Project".

For me, the solution would this: When you create a new issue in jira, you have a drop down list of people who you can assign an issue to. This list contains the users I want to be able to see in the user picker with the exception that it should also include users who aren't "assignable users". I don't want it that "internal users" can see everyone because in my installation we have no external users. All our customers have their own project and all users can create and update issues. HOwever, I don't want customers to be able to see each other and I restrict this using groups and project permissions.

Would this be possible?

Best Regards
Andrew

Hi,

The problem here is that we are not too sure how to provide this functionality. At the moment JIRA does not have any concept of what company a user belongs to. A 'company' does not exist in JIRA as an entity.

The only current work around is to only allow internal JIRA users to have the global 'Browse Users' permission, this way external users will not be able to use the User Browser.

One way to go about this issue is to only show users that are members of the user's groups in the User Picker. The problem is that a user has to be part of the group which is given the global JIRA Users permission (in most cases the jira-users group). As all users have to be part of this group this prevents us from solving the problem.

To get around that issue, we can ignore groups that have the global 'Browse Users' permission when showing the User Picker, and only show members of other groups.

There is another problem. I am guessing that internal JIRA users should be able to browse all users, even those that are not part of their groups. I guess this can be done by introducing another global permission called e.g. Browse All Users.

Alternatively, we can introduce a 'company' entity to JIRA and in User Browser show members of the same company. This is a much bigger change. And if we introduce a 'company' enity it will probably make a lot of sense to make it much more useful in other parts of the application, for example in Permission, Notification and Issue Level Security Schemes, Workflow Transition Consitions, etc.

Introducing a 'company' entity does not really solve the problem of allowing internal users to browse all users. Therefore we will still need another global permission.

All of this sounds too complicated to me. Please let me know what you think and if I am missing something.

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

Cheers,
Anton

I strongly agree - seems more like a bug than a new feature.

Revealing all companies that work with the buyer of Jira Enterprise via eMail-Adresses in the user browser is definitively a security leak.
Is anyone from Atlassian working on this?

Thanks for any update!
Andreas

This is the only thing that is stopping us from buying the enterprise version of Jira. I hope it can be fixed soon. This is a huge privacy issue. Please change it to a bug and have it fixed soon.

I confirm the above-mentioned problems. For us it is more than annoying and complicated to manage the work-around. We, my clients and my colleagues, vote to fix this as soon as possible!!! Thank you!!!

I also vote to fix this.
When a users adds mulptiple watchers for an issue I dont want him to see ALL users for every project.

same problem here - we consider this as a security issue, too.
in all cases JIRA is used in a closed multi-project mode for different customers this is really a problem.
i vote for a raising the priority, too!

stefan

I would vote this as a bug too. I have a custom field multi user select box within my project but by having this, I have to let all customers see each other when they browse users. Or I have to switch off browsing which is unacceptable to my users

Is it possible to raise the priortiy of this too?

Cheers
Andrew