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

So, we're using Jira Cloud and I have no problem getting the issue mentioned here to work. I do the following:

• Create project
• Create group with external clients
• Give group access rights to tag/mention other users
• Give group access only to aforementioned project

Now, when I, as an admin, log into one of those users' account, go to the project, and, say, add a comment, I can only browse the users who have access to that project, now other users.

This seems to be so simple and such a fundamental function to make Jira Cloud more useable.  Note that a Jira site of over a 1000 users, this becomes an extremely unmanageable list.

We have moved long time, supportive Jira Server Projects to Jira Cloud and this is a primary complaint and concern.

1. Makes the user picker more onerous on the user
2. Potentially allows for users to scan the user base.

This needs to be prioritized and executed on. 

How many votes are needed until Atlassian finally reconsiders a decision to not implement a feature that tons of users are still asking for?

Wow, 16 years gathering interest. Make my Jira queues look highly effective.

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

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

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

Any updates on this? 

So many years and no solution in sight. The typical Atlassian world. 

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.

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

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.