Users with browse users (global) permission are able to see all users in the system, even those in groups and projects they do not belong to. How to prevent this? Any help would be great, thanks!
I assume, the main issue here is the Browse Users permission in the Global Permission section. You need this permission, in order to easily search an user, but the final check, if an user can be added as watcher or not, occurs upon you click the selected user from the list. This is too late.
The restrictions depend on the field in which you see these users. In the Assignee field for instance, a given user will only see the users with Assignable User permissions. There are no further restrictions based on the groups in which the users belong. This would be hell and would make sharing work a nightmare in any company-wide instance. Imagine if you could only share work with users who belong in all the same groups as you.
Side note: If you see all users in Assigned or Watchers or Reporter, this means that all users have these permissions in that specific project. If they don't belong there, you should take a look at the project roles and permission scheme of that project and make sure only the people who need this project have these permissions.
They can be listed as watchers - the point of the field is that you can include anyone you want.
If a watcher does not have "browse" permission in the project, then they will not be sent any emails though, as they can't see the issue (there are add-ons that allow you to breach that security and allow you to leak, but that's another conversation)
The logic for this is simple - how does JIRA know that a user you add as a watcher might not be added to the project later? It can't possibly know that, so the code is kept simple - if you can see a user, you can put them in as a watcher.
The issue https://jira.atlassian.com/browse/JRASERVER-7776 was created in 2005 and it is still unresolved. So I guess, this is a basic issue how JIRA was designed and it is not easy to solve.
How does the global browse permssion work:
Ability to select a user or group from a popup window as well as the ability to use the 'share' issues feature. Users with this permission will also be able to see names of all users and groups in the system.
Right now we cannot share the browse users permission with external users. This is not just about watcher, but also other user multiple-user picker fields. Without the permission the users can use the fields, but they have to type in the exact username. Not very user friendly.
Right now I have a problem with the watcher field. Browsing for users to add them manually as watchers shows me the full list of all users, even those not playing any role in the project. I guess they can't be added as watchers, but they should not be listed.
If I click on the watcher field and select a name from a person that doesn't have a role in the project, I got the message from Jira:
There was an error adding watcher
The user "username" does not have permission to view this issue. This user will not be added to the watch list.
Does this really make sense?
Yes, it makes perfect sense - if I am trying to involve Dave in my issue, but he can't see it at all, then there's a red flag that I need to get him added to the project, at least as a read-only user (which might not the same as "adding them to the project" in other senses)
It's even worse if I have to go hunting around for why Dave can't be added as a watcher. In this way, a) I can find him easily and b) get told why I can't add him.
If you limit the watchers field to the project, then you make problems for yourself - when project membership changes, you have to start editing fields on issues, which is not sane or useful, and, as I said, the point of watchers is to include people, so you want the whole list.
With reference to the point:
when project membership changes, you have to start editing fields on issues, which is not sane or useful, and, as I said, the point of watchers is to include people, so you want the whole list.
We have the situation when users became inactive, left the company, etc. The watcher field then is just history.
I have a concrete case, that users shouldn't be able to see all the users in the system. I tried to remove the permission from the browse users permission and was expecting, it would work by typing in the username. But it didn't work.
Thanks for your suggestion, @Avinash Singh.
This is very important, especially being involved in activities with different external customers, I've removed the global "browse users" permission for most of the users, but this makes it difficult to find a user by start typing in a user field.
If im not mistaken the only place to @mention a user is on a ticket which is always part of a jira project either the comment or description fields.
If you remove users from the global "browser users" permission then those user not part of the permission cannot see any user all together. It would be ideal if they could see only users part of the project.
@Nic Brough [Adaptavist] If a customer is only part of a specific project then they will not have the issue where they can @mention in one place and not in another :)
If you dont mind sharing where else are user allowed to @mention other than the comment and description field ? Other free text fields?
Also if you had a custom field which is of type user picker, users will not be able to select users if they dont have the global "browse user" permission. The Assignable user permission only affects the assignee field not other custom fields.
I think you're missing the point - most of us do not have that one set up where it happens to work ok.
I did not say you could use mentions in places other than fields, just that I can use them from outside the context of a project, making the permission a nonsense, as well as inconsistent in behaviour for users.
A user picker without "browse user" still works. The users have to know who they are going to select though. User pickers in later versions of Jira (I seem to remember since 6.3) can have their user list restricted to a particular role or group, which might help in your case.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hi, everyone! Molly here from the Jira Service Desk Product Marketing Team :). In the spirit of this month's august-challenge, we're sourcing stories of Jira Service Desk activation fro...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs