Limit/Restrict User Browsing

[Tobias Brunner (Admin Account)]

Is it possible to limit user browsing so that a user only can see other users which are in the same group or in a configurable group/groups? We do not want to grant the "Browse Users" global permission so that every user can see every other user for @ mentioning. But without the "Browse Users" global permission the mentioning doesn't work

[Nic Brough -Adaptavist- · Accepted solution]

No, you can't limit the group visibility to "same as me"

Atlassian have not even tried to implement it.  It is a bit of a pain for certain cases, but there's massive logical problems with implementing it.  Off the top of my head:

• The default in JIRA is to have a group for "user can log in".  All (active) users are in it.  So if you were to implement something to do that, everyone would be able to see everyone else because they can all log in.
• If you split all the groups down, you make a massive group maintenance headache for yourself - you have to micromanage every single group, even to the point of adding a new user meaning you have to go in and remove them from all the default groups
• You make it almost impossible to manage projects accurately (unless every project is strictly limited to a specific set of groups) because your user fields have two layers of logic in them.  For example, assignee = role X, and then "is in same group as me".  Then you start getting questions like "Why can Alice assign the issue to Bob, but I can't?  Even though I can assign it to Charlie?"
• User permissions and group management is already a big performance drag on JIRA.  Limiting it more means more load and it's entirely conceivable that you'd cause more performance problems.
  
  I'm sure there's more.

[Gabriel Radic]

It would make a lot of sense to move permission to "Browse users and groups" from the global scope to the project level.

As a project team member, I want to browse only people from my projects instead of the entire directory or users and groups.

[Nic Brough -Adaptavist-]

I'm afraid that is a non-starter.  Working out "who is in my project" becomes exponentially difficult because of Jira's flexibility, and, quite often, people are using mentions because they want to draw in someone who is not "in the project".

I would like something that skips groups and uses its own rules.  I should be able to group users into silos and people can only see people in their silo.  With the option to make any silos globally available if necessary (e.g. everyone can see the support team silo, even when they're not a support person)

[Gabriel Radic]

Jira does the "is user on project" check already when deciding to show or not the project in the dashboard and elsewhere.

[Nic Brough -Adaptavist-]

No, it does not.

It checks if a user has view issue, and create issue.  Project "users" can be a lot more complex than that.  Those are relatively simple checks, optimised, nothing to do with other users, and are absolutely not "is user on project" checks.

[Gabriel Radic]

Maybe I don't fully understand this, but when a user opens the dashboard, or the list of Projects, there is a check for what projects their see. Surely this trickles down to each project's People (and Groups) list. So it's not that crazy. 

But, again, I may be seeing things. 

[Nic Brough -Adaptavist-]

No, it's not that simple.  It checks view access.  Which is NOT the same as "person in the project".

[Konstantin Trunin]

This is critical security breach! Why it is still not fixed??!

[Nic Brough -Adaptavist-]

I don't think you understand what the problem is.  There's no security breach, just something that's painful to implement and not a lot of use to most people.

[Konstantin Trunin]

Are you saying that not many people need to restrict one project's information (including it's users) from other project users?

I believe it is a base requirement if you have more than one client.

[Nic Brough -Adaptavist-]

Yes and no.

I'm saying that there is no need to restrict users, you should be talking about what you allow them to do.  And yes, it's complex and painful to do this by project.

If you're worried about users seeing each other, you currently have to turn off "browse users" as a global option.

[Konstantin Trunin]

Displaying information that belongs to other client to everybody it is huge security breach in JIRA.

And turning off Browse user will make Jira quite unusable - so this is not a valid option :-(

[Nic Brough -Adaptavist-]

Actually, both of those are very minor points, especially in a tool that is explicitly built for collaboration.

[Konstantin Trunin]

If collaboration is justification for this defect then then why JIRA has roles and permissions??? ;-))) Let's collaborate everybody with everybody

What about NDAs and other information security restrictions that exist on the projects?

JIRA should allow for collaborators to see only what they are allowed to see.

[Nic Brough -Adaptavist-]

I still don't think you've got it.  Jira does support that.  You're not looking at it right.

Please, go read the accepted answer again

[Peter Hochstrasser]

Nic

You might have to reconsider that GDPR has nothing to do with it.

One of our customers is not willing to be seen by other customers of us. So, he executes the right to privacy for himself.

Doing the obvious, namely removing the "browse users and groups" global privilege, prevents everybody from browsing that customer (and all other users) - and removes @mentions.

That's why GDPR would more or less require that Atlassian puts an opt-in on the user. That would make things not a lot faster, I know - and it would also prevent this user to get @mentioned period. Even in his projects. So, we'd need an exception to this rule...

The full picture would be that we'd need a way to restrict browsing to project members. Using groups, you can create some exceptions to that (by, for instance, having all of your devs in all of your project's privilege lists). But I can't think of another scheme that would solve things in a team cololaboration friendly and GDPR compliant way.

[SK1975]

We have the same issue:

"It is a bit weird that even if you use custom permission scheme, and lets say give a specific group of external users (client) specific permission to Manage Watchers and View Voters and Watchers, they still can't do that because global permission says only our internal groups can browse users.

Like a bunch of others in the community, our clients must not see a list of all JIRA users, but they should be able to see/mention/add to watchers users who are specifically assigned to that project like how it works for Assign a user.

Sorry for reopening this, but I am desperately trying to find a solution, it still evades me."

Thanks!

[Altuğ]

Hi there,

I agree that it is an important problem which needs to be resolved. I also don't think that it affects limited users, most possibly they didn't want to spend time to struggle it.

I struggled with this issue several years ago and couldn't resolve. Whenever I add temporary users (generally outside of my company) to a project team, I needed to decide If I want them to access all users list in my company or not.

I assumed that Atlassian Team might recognize this problem and at least provide a workaround as solution. Now I'm sitting on the next side of the table as business owner and I have vendors...

Currently we are working with a vendor with 5.000 users. They are using on-prem version of Jira. They created a new Jira Project for us and created temporary project users for us to let us open our issues over Jira. Once I realized that I can't use mentioning functionality, I asked them to allow us to mention. However, the answer was:

"Due to GDPR, we can't give you the rights to use mentioning"

I think they are totally right. Otherwise, I'll be able see each and every users' names, profile photos etc. working in their company. I can even mention their CFO, which is ridiculous.

So please consider again to provide "limited mentioning rights" functionality which allows users to mention only the people who are in a specific group. 

Thanks...

[Nic Brough -Adaptavist-]

Thing is, there is no "problem" here, and GDPR has nothing to do with it.  People you choose to have access have it, other people do not.  If someone has an account, they've agreed to use the system, including getting email from it.

Quoting GPDR here feels like someone does not understand the law at all.  I'd start to fix this problem by questioning the misunderstandings.

[Goran_Dermeta]

nic, as far as we understand GDPR, there is a problem, but from the usage POV:

• imagine we have 2 competing clients, each has its own project in our on-prem JIRA
• now imagine that we enable Browse User functionality for both user groups, which consists of employees of each client,
• now both clients can see other's employees plus all our employees.

If there is a contract not specifically stating that client agrees with showing all of his employees to all our other client' employees, we would be breaching GDPR. As without consent on being visible and being able to see others, this doesn't work.

We can't offer a contract allowing that, and here you are right, this is not a problem of GDPR, but of business and trust. 

But now I have another problem. This function started to work for reason unknown to me. I added a client user group to one project, assigned Browse users global permission, and viola, external users see only users, who have e.g. browse permission on that specific project.

[Isaac_nl]

This is exactly the issue we are facing. With browse user permission enabled, JIRA is sharing our clients email addresses among eachother. So email addresses are being shared outside of the agreed scope in the DPA, so strictly speaking it's a GDPR problem. Disabling browse user pemission makes JIRA quite a lot harder to use.

There's an open feature request: https://jira.atlassian.com/browse/JRASERVER-40283

[Pouján (Jiralísta)]

Nic, it seems like you are mixing security of issue info with user info. Jira does not support limiting or adjusting capability of users to see/browse only a certain group of users, particularly those in a project (as defined by user in any role in a project).

This is a crucial missing feature with regard to GDPR. I don't understand why you are trying to justify or downplay it. It IS a big blocker in EU and Atlassian needs to do something about it, if they don't want to lose customers particularly in Europe with its strict GDPR rules.

Best

[Goran Dermeta]

It is a bit weird that even if you use custom permission scheme, and lets say give a specific group of external users (client) specific permission to Manage Watchers and View Voters and Watchers, they still can't do that because global permission says only our internal groups can browse users.

Like a bunch of others in the community, our clients must not see a list of all JIRA users, but they should be able to see/mention/add to watchers users who are specifically assigned to that project like how it works for Assign a user.

Sorry for reopening this, but I am desperately trying to find a solution, it still evades me.

[Scott]

I have the same issue. We have JIRA Core deployed and need to be able to restrict who can view/browse a project due to the sensitive nature of the work.

[Nic Brough -Adaptavist-]

This thread is not about who can see projects, its about who can see the user lists.

Sorry, belted "send" too soon on that, and then went into a tunnel with no reception.  Here's what I should have said before posting:

Jira does not restrict, it only grants permissions at the project level (issue security is a different story).

In theory, this is really simple, because all you have to do is set the permissions so that "users matching a rule can see the issue".  That grants permission.  It is often by saying something simple like "users in the role of 'user' in the project can see it", and then putting the users (or groups) you want into that role in the project.

But.

Jira ships with some terrible defaults which automatically grant access to anyone with a login, and before you can use the simple, sane and reasonably intuitive rule above, you have to unpick these dreadful defaults, so that you can actually do it.

There's a good guide to it over at https://community.atlassian.com/t5/Jira-questions/JIRA-Software-project-permission-restrict-user-access-to-one/qaq-p/779572

[Scott]

Thanks Nic...sorry about posting in wrong topic thread. I will heck out the link.

[Nic Brough -Adaptavist-]

No apology is needed on your side - I'm happy that you found a thread that looked related and you asked.  This conversation is messy and unclear (unintentionally of course), and it's better that you asked and got a pointer, than stayed quiet and got nothing.

On my side, an apology was the right thing - my accidentally shortened post was terse and grumpy-looking and gave no useful guidance.  It wasn't what I wanted to leave you with, and I'm hoping the correction was better!

[Joe Pitt]

Sort of. You can apply security schemes to issues that limit access. You can setup a default security scheme. Check out https://confluence.atlassian.com/jira/configuring-issue-level-security-185729623.html to start.