Piotr, some of us are still using add-ons that allow us to use Watchers in Security Levels. In any case, we had to use an nginx rewrite rule to revert back to the old behavior for us.

1be02dd9cac8 Watchers can't be added to an issue security level, a workaround is necessary. Cf. JRASERVER-5982.

For me, this is not a consistent solution. The ticket view does filter for authorized users now.

If I open the "Manage Watcher" view in the menu "More->Watchers", I unfortunately still see users without authorization for the project.

We have a total of over 20000 users in the IDM, of which a maximum of 250 can act as watchers. The auto-completion is thus almost ineffective! You almost always have to enter your full name to get a real match. Such a nice help (the auto-completion!) becomes useless with it.

This feeture would be very usefull and I don't think it would be so difficult to implement it !

Please consider the currently windows is very poor and "refusing" people who do not have access, after adding them is not very easy to use.

It would be great to propose only people who have access to the project.

We still hope that this ticket will be solved while it is a teenager... Currently sixteen years, right time to be prioritized.

Still actual issue, is there any plans for solution?

GDPR+1, i filled the same issue as bug: GHS-176556

We've had this feature enabled and we've just realised that we have customers seeing other customers details. This is not a nice to have feature but essential. We've disabled the feature and now we have screaming customers. This put us in direct violation of GDPR. Please can you get this working.

Wow, looks like I own the privilege of making the first (and currently last) comment on this issue! While I agree this would be a useful improvement, I think it's a bit heavy handed to say you need to abandon JIRA because of it. Can't you just not use/enable the Add Watchers feature? In my installation, I'm the only one with that permission. No one here even knows that feature exists so it's not an issue. I often use my analogy to windshield wipers. When they were first on cars there was only on and off. Now virtually every car has intermittent wipers, which is a great feature. Let's say the intermittent feature wasn't working - they were only on or off - would you say the car is undriveable? No, just this nice feature that I would like to use isn't working. But I can still drive my car and clean my windshield (windscreen for our U.K. and Australian readers). No need to abandon the whole car. Anyway, that's my turn on the soapbox. 

Is there any further update to this issue - any workarounds or solutioning plan?

I have raised this with Premier Support. In the absence of a workaround, can this get some traction?

This issue is a security risk. Imagine a Jira platform where multiple companies are interacting on different projects, where each company doesn't know of the other's existence of that platform.

In this scenario, the watchers list exposes all users! How does Atlassian plan to address this?

Still relevant.

For the scrum projects we would like the non admin users to be able to add other members from their team to receive notifications.

We do not want to add notifications to the whole team as that would be too much notifications.

We can't permit customer- users from different companies to see name and email of users from other companies, so we can't allow them to have the Manage Watcher permission.

So please higher the prio on this

If this bug is not resolved and the companies with JIRAs set up do not turn the watchers off, they risk financial penalties (read: ruin) for breaching GDPR EU law if anyone vindictive gets the wind of this.

Atlassian can literally lose their clients (to their bankruptcy) because said clients using an Atlassian product.

Same here. We connected jira & confluence, the users & groups are managed in our AD. We have a group named "jira_users" and one named "confluence_users".

So, clicking on "watchers" on a ticket-page to manage watchers opens an user-picker which lists all users - jira_users & confluence_users. Picking a confluence user results in an error-message (basically it says "no permission" because users from group "confluence_users" have no permission to our jira). These users should be filtered before!

For example, clicking on "assignee" results in a user-picker where users of the "confluence_users" group aren't shown.

Our users reported this as well.

Please restrict / pre-filter the watchers (at best also the reporter field) to users who have browse project permission. This way confusions about why users are showing up in auto-complete would completely disappear. Also it's a great addition in terms of consistency.

You should think about abandoning no pre-filtering on project scope. In administration scope, however, it is a must that there is no pre-filter applied; thinking of user picker custom fields, default reporter for email handler and so on.

Hi beautiful Atlassian team!

Please restrict add watcher list. ** 

our user story: 

1. Project A - for developers and managers, where ~200 persons have access.
2. Project B - for others persons (include customers), where ~9000 users worked with project. Therefore users from Project A annoying about collissions, a bigger list for example,  if I type "Tom"  - I have seen 266 persons.**

Thank you. 

Best reagards,

Gonchik Tsymzhitov

As Michael Dennis mentioned in above comment, we see same issue while adding watchers. Please restrict add watcher list

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

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

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

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

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

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

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

See also JRA-36896

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

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

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

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

We are using JIRA and JIRA Service Desk (JSD) Cloud - It is simply amazing that this works the way it currently does, despite the explanation that it "works as designed".  It is actually 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.

Would love for this "feature" to be added. Have the same issue.

https://support.atlassian.com/servicedesk/customer/portal/23/JST-201480

Thanks for the reply, it explains a lot.
Regards,
Ryszard Łach.

Hi ryszard.lach,

Yes, I reading every comment for every issue on which there is an update from me. As a rule, we update all issues at a minimum of once every 6-12 months and occasionally more frequently for requests we are actively working on, as well as address occasional comments. Unfortunately, it's not realistic for our small PM team to respond to every comment and creates unnecessary notifications for other folks watching the issue.

We don't consider this a bug because JIRA's user picker was intentionally implemented this way – for JIRA instances where all users are part of the same company or organization, the current behavior is logical and preferable. In general, JIRA's feature set was not designed to completely isolate projects from one another. While we would like to support the ability to add more granularity to the user picker to support use cases like the one you've described better, it's a new feature we need to add to the product, and therefore we need to continuously re-evaluate it against all other priorities.

Regards,
Dave Meyer
JIRA Product Management

Does anybody from Atlasian read these comments?

For me it is a painful security bug. We have 500 user Jira license, working on jira with several customers in total independent projects, their users SHOULD NOT KNOW ABOUT EACH OTHER. This is even a legal problem - polish "Personally Identifiable Information Protection Act" (Ustawa o ochronie danych osobowych) requires, that anyone, who has access to view my name and e-mail should be explicit allowed to do so by me. I cannot ask my customers to agree to show their personal data to other customers.

How can this bug remain unresolved since over 10 years?

My expectation is simple: Users not playing a role in the project should not be listed. The reason is, we don't want to show to everyone the users we have. This is also a matter of confidence.

I have the same problem.

https://support.atlassian.com/servicedesk/customer/portal/22/JSP-252883

Hello every one,
we have the same problem. (Jira 6.3.10)
Was the problem fixed?

@dave-- I don't mean to pollute this thread, so certainly happy to continue discussing in JRA-39682, however I have to believe there's a way to handle this without degrading functionality. Maybe "users in x role can see users in y and z role"? Or link it to something beyond roles? Watchers can maybe work the same way.

@Matthew - I understand the security component you raised, but I don't think limiting the assignee and reporter suggestions during search is a good idea. Role memberships can change over time and it would significant degrade Jira functionality if the user picker for assignee and reporter searches were limited based on current role membership.

Adding a note that this also happens in issue search, in the assignee and reporter searches. That's really a problem for us. I made JRA-39682 about it.

I'm adding my vote to this. This is a major security issue for us as it gives every client access to our entire client list.

+1 to the above.

It's insane. It's a serious bug which should have been resolved since long. In our case it's exposing the names of different customers to eachother. In terms of privacy, this is bad.

This issue impacts us too.

I hope that it will be fixed some day.

Hello Monique Cardino,

it is unbelivable that this issue is still open and that there is no planned version for fixing it.

BR Stefan

I just commented on JRA-7467, which is basically on the same problem.

IMHO there need to be new permissions that the (default) user picker takes into account. Please see my comment over there: https://jira.atlassian.com/browse/JRA-7467#comment-430719

Still unresolved after 7 years.

I was hoping this might have been resolved with JIRA 5 and the new inline editing capabilities, but it seems to still linger. Any chance it might get some attention soon?

After more than 6 years, it is incredible to see this kind of issues unsolved...

I'm managing an instance with more than 6000 users and more than 900 projects. I'm really afraid to see the user picker is unable to respect the permission schemes.

I have an equivalent problem. When a project grants a permission to change the reporter, the user picker does not respect the permissions associated to the project. Unbelievable. I'm using JIRA 4.3.4.

Ditto on last comment from Ian above!

Hi,

Adding my 2 cents.

As everyone above has stated, this issue is causing some grief in my company. Considering this issue has been around since 05 and the limitation of assigning issues to multiple users, I would think this would be a higher priority.

I would much prefer this get resolved, then a new pretty interface for viewing projects.

Thanks,
Ben

Hey,

For each customer, we defined a project in Jira and the customer who has access to his project can can make changes depending on his role. They can also specify watchers on this issues, but, when they open the whatcher list, thy can see also the users and the email adresses of our other customers who are assigned to a role of other projects. In total, we have 1109 customer users + our own users, that a huge list of Jira users. Because, a user can only receive email notitication if he is assigned to a role of that particular project, I don't know why it is possible to select a users who is not assigned to a role of that project. So, I can't see the reason why the list shows all the jira users and not only the Jira users assigned to a role of this project.

Regards,
Evelyne.

I'm not convinced that all the impacts of this issue have been stated above, and as such I've written a (somewhat lengthy) summary of the issue and its impacts. Of course, I'm doing this to try and gee up Atlassian to address the issue. In particular, the issue introduces some security concerns that I really think that Atlassian should address.

For starters, the title of this issue refers to watchers. In fact the problems stated are not limited to adding watchers. They hold for any User Picker field other than the Assignee field. That is, the Reporter field, and any User Picker or Multi User Picker custom field.

Environment

The problems exist in any JIRA instance in which some users have access to a limited number of projects, and must not know of the existence of any other users in the JIRA instance. For example, if the instance is used by a company to support multiple customers, but where there is a legal requirement that each of those customers not know about each other. Each partner only has access to a limited number of projects.

Let's call these customers the external users. In addition, there are a set of internal users who must have have access to all projects and know about all users.

Underlying Problem

When a user is adding a watcher or editing a User Picker field (a custom field or the Reporter field), the user can select any user in the system. JIRA does not restrict the set of users that can be selected to those that have access to the project.

Impacts

Usability

Impact 1: the popup window for selecting users displays far too many users

Users that have the Browse Users permission are able to select users from a popup window and use auto-complete to select a user.

Let's say an instance has 5000 users but there are only 50 that have access to a project. A user goes to add a watcher or to edit the contents of a User Picker field. The popup window displays all 5000 users in the system. The user has to wade through them all to find one of the 50 that it makes sense to choose from.

(See Impact 3 below for the related security impact.)

Impact 2: adding watchers, or editing a User Picker field is almost impossible if you don't have the Browse Users global permission - and it isn't safe to grant Browse Users to external users

Anyone with the Browse Users global permission can see all the users in the system, via a popup window that allows them to navigate through all the users, or by using auto-complete, when they edit a User Picker field or add a watcher. If the system is configured so that email addresses are visible, the user will be able to see the email addresses for all the users in the system.

Consequently, in a JIRA instance such as I described above, only internal users can be granted the Browse Users global permission.

It is often important for the set of external users who have access to a project to be able to add other external users as watchers, or to edit an issue and add them to User Picker custom fields (e.g. to a Reviewers or Approvers field). However, because these external users don't have the Browse Users global permission (as just explained), the only way that they can select a user is by knowing their exact username (e.g. jsmith). They can't select from the popup window of users (the "little men" button that launches the window is greyed out), and auto-complete doesn't work. They can't type the user's full name (e.g. John Smith) or their email address. It has to be the exact username.

This is next to useless.

Security Holes

Impact 3: Users can keep trying to match a username until they get a successful match - and the matched user might not have access to the project

That is, "I wonder if Jane Doe from Company X is using this system. Let's try to guess her username by adding her as a watcher or editing a User Picker field. Let's start with 'jdoe', then we'll try 'jane.doe', etc."

If a user does not have the Browse Users global permission, they can still try to guess the username of another user in the system when they add a watcher or edit a User Picker custom field. They have to guess the username correctly. If they guess wrong, JIRA says there is no user with that name. If they guess correctly, however, the user is added as a watcher, or added to the User Picker field, even if that user does not have access to the project. And once they have added the user, the user's full name is displayed with a hyperlink to their user profile, in which their email address will be displayed if the system has been configured to allow this.

One can easily imagine something an automated attack via the REST or SOAP APIs, with a program continually guessing usernames until it gets a match.

Impact 4: Internal users can erroneously add a user who does not have access to the project. External users hence will know of that user.

Internal users, who do have the Browse Users permission, are confronted with the complete set of users when they go to add a watcher or add a user to a User Picker field. It is a simple mistake for them to select the wrong user, particularly using the auto-complete interface. They could add an external user who does not have access to the project.

Then when an external user who does have access to the project goes to browse that issue, they can now see the name of a user who they should not know the existence of. They can click on the hyperlink for that user to look at their profile.

Re-iterating, the "false watcher" or "false user" does not actually have access to the issue. It just looks like they do. It certainly looks like that to the external user who accesses the project. They could get very upset: "Who is this Fred Nurk who has access to this issue? They don't work for any of the companies that have access to this project. Why do they have access to our stuff?"

Proposed Solution

1. Limit the users that can be selected (when adding a watcher or when editing any User Picker field) to those that have access to the project.

AND

2. Make Browse Users a project permission (in the permission scheme) rather than a global permission.

Hi Vincent - great work on the new Minyaa Suite. Is this feature of displaying project users (only those who are part of the project) also working during the life-cycle of a ticket (issue creation, editing, resolution)? We have custom fields (both multi-users and single user user-picker type) that provide selection of users who will work on the ticket (ie. Responsible, Accountable), and we would like to show in the user picker pop-up window only the users who are members of the project where the ticket belongs.

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

Our organisation is affected by this issue and would like to see a solution implemented.

Can you give any indication of whether it is under consideration?

Same here. In our opinion an important feature. The autocompletion of the watchers field is a good feature but not really usable when you have multiple customer projects in one Jira installation.

Any update on a release would be great.

I have also voted and am watching this. I think this is a pretty helpful feature to have.

This is causing our organization a great deal of grief. I am voting and watching this issue as its resolution would greatly help.

So, We're running JIRA 4, and in it there is a permission called "Browse Users" in the global permissions. This permission allows you to grant or not grant permission to users to "browse" the users in the user-select fields, requiring people to know other users usernames. This works in our organization, as usernames are the persons email address.

Hope this helps.

This is an important one for us also, users are currently adding users as watchers when those user do not have access to the project. It causes a lot of confusion to users who expect that if they can add a watcher, then that watcher should be able to watch the issue. It should not be possible to add a user as a watcher if they do not have access to that project.