Browse users permission should be restricted to shared projects

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!

14 answers

1 accepted

This topic is old, see https://jira.atlassian.com/browse/JRA-7776

With JIRA 6.2 there is a "limited user picker" as announced here: https://jira.atlassian.com/browse/JRA-7659,  but this does not cover the watcher field.

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.

1 vote

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.

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

Browse Users

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.

0 vote

The whole point of the watchers facility is that people can be watchers without having to be a user in the project.

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?

 

Yep, this is to be expected. In the Permission Scheme, there's a Watch Issues permission. Set it to the Viewer Project Role (and above), so that all users who are at least viewer can be watcher

Sorry, not true what I just said. They need the Browse Project permission.

0 vote

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.

I agree. Users should not be able to see other users in the jira system. You should be able to control this via the permission scheme. The browse permission also affects @user_mentions.  This way users can see the entire user base.

No, that's nonsense because most of the time you're not in a project so you could have different rights at the same time.

If you need to stop users seeing each other, remove groups from the global "browse users" permission.

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.

Yes, you are mistaken, and it would look stupid to a user as well if you did it by project - why can't I use @mention in one place and I can in another?

@Jose M. We have the same problem where we dont want customers to see other customers but only see our internal users.

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

0 vote

I'm afraid that the watchers field is not of any use unless you can draw everyone in, that's why it's been done the way it has.

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published Thursday in Jira

Meet the AUG leaders of Northern Virginia

@Rachel Wright (Jira Genie), @Billy Poggi (AUG NOVA, DC), and @Dana Jansen (Confluence Queen) are just some of the folks that lead one of the world's most active Atlassian User Group (AUG)....

157 views 5 9
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you