nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Call for feedback - Atlassian cloud people directory user visibility

Rusty (Matt)

Please note - the logic described in this post is no longer in place. Instead, all users can see each other in the People Directory, and administrators are able to leverage the Browse Users permission when using Jira to restrict access to People Directory, along with other people browse/search experiences like mention or assignee.

There are currently no user-to-user visibility restrictions available in Confluence.

Hi Community,

I'm a Product Manager at Atlassian, responsible for the new people directory on Atlassian Cloud. Its part of our integrated profile transition, allowing you to see users profiles across both Jira and Confluence in one directory. It will replace Confluence's people directory soon.

You can get to it today by going to yoursite.atlassian.net/people.

We are about to start featuring the directory more prominently over the coming weeks and I was looking for some feedback on a couple of points. Visibility of other people can be a touchy subject, and we want to start transitioning from a configurable people-visibility approach to a "smart-default" approach.

Today in Jira, administrators can grant the "view users and groups" global permission to groups on their site. This controls who can see other users in things like user pickers and mentions. By default, this permission is granted to the license group, but many customers customise this setting.

We want stories to help us understand why and how administrators are applying this setting at Jira.

Today in Confluence, it is not possible to restrict visibility of other users, as all licensed users appear in the directory, mentions, and user pickers. There's a customer suggestion to allow similar configurations for Confluence.

We want stories to help us understand why and how administrators are applying this setting at Confluence.

We think user to user visibility can be improved. We use visibility rules in the new people directory that we believe are better suited to collaboration. We want your feedback on whether we've got it right or wrong. Most importantly, we want to understand why...

Who can I see, and who can see me in the new people directory?

When viewing directory, you will see a blend of two sets of users:

All other users on the site who’s email domain matches yours. This excludes a set of known email public email domains like gmail.
The last 30 users you have collaborated with, based on 90 days of activity. Collaboration is defined here as any non-view event (e.g. creating, editing, commenting, liking, watching) on any of the same content.

Anyone you can see based on these rules can see you too.

We plan to allow Administrators to see all users on a site, as an exception to these rules. This would mean an admin could possibly see a user that cannot see them. This won't be in place on day 1, however.

We chose this rule set after careful consideration, as it creates a set of natural soft boundaries of collaboration within a cloud site. Businesses with a simple setup of collaboration within the company will be able to see all other people from the company, businesses with a more complex setup including vendors, clients, or contractors won’t unintentionally reveal all other users on the site.

This rule set only applies within people directory at this stage. The Jira configurations are unaffected.

People directory will replace Confluences people directory in the near future, and be available for all licensed Jira and Confluence users on a site.

Again, you can get to it today by going to yoursite.atlassian.net/people.

I'd love to hear why you think these rules are great or terrible, and whether they will help you or hinder you getting more s#!t done.

Comments

Andy

Seems sensible, but to be honest the only part I'm interested in is whether this will address the glitch where anonymous users can find placeholders for user profile pictures via search - should find nothing.

Roel Croonenberghs

We use confluence for communication/collaborating with customers. We would like our employees to be able to see everybody. But our customers can only see users from their company.

We have basically 2 kind of groups. 'employees' 'customers' Where customers contains subgroups per customer 'custA' 'custB' 'custC'...

View/edit restrictions are setup based on these groups.

So it would be normal to have the ability to restrict the users you can see based on these groups.

Employee can see all confluence users. 'custA' can only see users from group 'custA'. 'custB' can only see users from group 'custB' ...

Filtering on email domain is not useful because users can register with different domains, but still belong to the same customer.

Why don't you put a setting: 'can only see users from my group yes/no'

Arjan Salomons

Thank you for paying attention to the user browser on Confluence, Matthew! As was being stated in issue CONFCLOUD-7837, having the User Browser wide open to all my clients is not something I asked for.

Also it is not GDPR-proof.

I have a couple hundred projects in JIRA (I'm an admin for a couple instances using Cloud) and a dozen Confluence Spaces, all neatly organized and rights set per client. The only thing that is not private, is this user browser.

Please make it as simple as a check mark (or group setting/right) to enable or disable the people browser. As a start, the option of not showing a link to it in the sidebar would be very helpful.

Gabriel Radic

I absolutely agree with this:

> View/edit restrictions are setup based on these groups.
> So it would be normal to have the ability to restrict the users you can see based on these groups.

It's a clear, intuitive rule and permission: "See users in the same group." This should not include the broad access groups like confluence-users or jira-users.

Dave Winter

I totally agree with this comment. This absence of security is a major blocker for rolling out a project's confluence space to a customer.

We also restrict employees access to customer spaces as part of data protection of customer information. Employees should only see information on projects they are working on and not be able to browse the whole people directory.

Major hacks can occur from within. The product as it stands today is weak. Closing this security gap is key for continued use of Confluence.

Thanks

Dalectric

I agree with the point made by Arjan and Roel. It seems strange that user privacy is not already a feature of the Atlassian toolset, especially when we are working with different customers and suppliers. They should not be able to see each others's details unless they are involved in the same project.

Normand_Carbonneau

For us, the business cases is as follow:

We have employees and customers
All employees of our company should be able to browse everyone. This being said, I would not expect any employee being able to use @mention with someone from Customer A on a Wiki page of Customer B.
Customers should only see people from their group, but is it important to restrict them from viewing all employees? I guess it may be for others.
And of course, people from Customer A should NEVER be able to see people from Customer B

Jim Lynch

+1 for all of Normand's requirements!

In this revamp the @ mention system needs to be looked at. Our customers are expecting to be able to use the @ mention system and that gives them visibility to all users.

I also hate using groups as currently implemented because there is no way to see who is in a group when looking at an individual project. Troubleshooting access/rights would be much easier if there was a way to hover over a group to see a popup with its members, or a link opening a list of members.

Dalectric

For Confluence I've taken to adding a page to each space to show group membership with the User List macro. It's not ideal, but it's a start.

Of course this doesn't help for JIRA, BitBucket etc. There does need to be someway to show the members of groups on all Atlassian apps.

IntelliDynamics Administrator

We have employees and multiple corporate customers. Our needs:

We would like to share a common space across all employees and all customers from each corporation. This common space contains product documentation, how-to and training materials, etc. While shared, customer users can only "see" our employees and other customers within their corporation.
Each customer would have one or more spaces for their specific implementations of the common products, likely in multiple spaces per customer (divisions, facilities, etc.) and have hyperlinks to the common shared space. Users in this area can "see" (in directories, @mentions, etc.) others users within that space and also our employees. The members of this space can NOT have ANY visibility, or even suspect the existence of, other customers in other spaces.

I think if you provided groups containing users that could be assigned ability to see other groups and associated members or not, and those groups could be assigned to one or more spaces, I think you would have it.

Carl Cook
President / CTO
IntelliDynamics

Rusty (Matt)

Thanks for the feedback so far everybody. I'll take some time to consider and potentially reply to each comment here, but just wanted to let you know I've received and started to think through the comments.

Keep them coming!

Roel Croonenberghs

This exactly the way we are using confluence in our organisation.

Gabriel Radic

To distill the most useful access rule into the simplest and most intuitive permission, it would be: "See all users on the project"

Björn Wennerström

We use different Confluence spaces for different clients and everything has watertight separation except this one thing. We would love to separate visibility of users as well. There should be a way to prevent the global list of users being exposed across spaces. Respecting the existing access groups would make sense for example.

Rusty (Matt)

Hey Andy - is there a ticket you can point me to for this on jira.atlassian.com? I can double check whether it's been resolved with the new directory.

Rusty (Matt)

Hi @Roel Croonenberghs & @Gabriel Radic,

If I'm understanding correctly, what you're describing sounds like it is fairly close to the rules we have in place. If we apply the assumption of email domain creating an automatic grouping / permission. But you've suggested that doesn't hold up - can you help me understand better?

users can register with different domains

Do you mean that customers you invite are able to sign up with emails of their choosing? Or do you mean that customers are made up of multiple email domains? Or do you mean your company has a mix of email domains?

Just trying to better understand how reliable / unreliable email domain is as a point of logic.

Why don't you put a setting: 'can only see users from my group yes/no'

It's our preference to try and create a set of rules here that require no setup or maintenance, and provide the power of browsing users in mentions and user pickers to all end users.

The setting you've described sounds like a lot of administration overhead to ensure people who need to work together across company/customer are in the same groups. You also might need to have flags on certain groups like license groups to avoid sharing visibility of users within those groups.

Interesting to consider though... will add it to the list.

Rusty (Matt)

Thanks for the feedback Arjan, @Dave Winter,

We would like to avoid a total blackout of features for users. Customers are people too, and deserve an experience that's first rate. A "blackout" approach is a last resort, and while we might explore depending on the insights I get out of the feedback here, we'd really like to try and avoid it.

If we are to allow disabling this new directory for people, you're suggesting they shouldn't be able to see other users on the same email domain as them, and users that they have collaborated with. Is that correct?

Rusty (Matt)

Thanks for the feedback @Normand_Carbonneau, @Jim Lynch, @Dalectric - I think Delectric has hit the nail on the head here.

Mentions within the context of a piece of content can be scoped to something like "who has access to this content". That becomes a very granular rule, and potentially confusing that I can see someone in situation A, but not in situation B.

At Atlassian, we regularly mention people who might not have permission to someone, because it creates a link to that person's profile. For example you might be doing a reorg of a department and have a restricted page, and mention all the people in the department so that people know who is who in the zoo.

So I think there are arguments in both directions for allowing mentions of people who don't have access at the content...

The directory experience, however, doesn't come with a "who has access to this content" attribute to create a visibility scope for. This makes more general / unmanaged rules feel more suitable, because we don't want everyone to have a broken experience until an admin realises how they need to set it up...

I'd love to know whether you think the directory rules are suitable based on our rules.

Rusty (Matt)

Thanks for this feedback. Can I ask you to get in touch for a face to face interview? I'm not sure I am clear on your purpose behind this setup. And I'm unclear why / whether the email domain rules described for the directory would or wouldn't be in breach of your current setup. I think a conversation would go a long way.

Feel free to reach out to me on LinkedIn to coordinate a time / share your details. https://www.linkedin.com/in/matthew-russell-81539510/

Rusty (Matt)

Hi @Björn Wennerström - did you have a read of the rules described for the new people directory?

This is exactly what we're trying to achieve, with zero setup / maintenance required.

When viewing directory, you will see a blend of two sets of users:

All other users on the site who’s email domain matches yours. This excludes a set of known email public email domains like gmail.
The last 30 users you have collaborated with, based on 90 days of activity. Collaboration is defined here as any non-view event (e.g. creating, editing, commenting, liking, watching) on any of the same content.

Anyone you can see based on these rules can see you too.

Let me know whether these rules fit your needs, and if they don't, it would be great if you could help me understand why.

Roel Croonenberghs

Yes, customers gives us a couple of users and email addresses. These are not always of the same domain. We put these users in 1 group. And all view en edit restrictions are based on this group.

So working with email domains will fail this.

"sounds like a lot of administration overhead "

Ye sit is. But apart from the user visibility, I don't see any other way of doing this. How can you let some users be able to see pages/spaces and define who can edit. Using groups and assigning users to groups seems the only way. The overhead gets as big as how specific you set up the restrictions.

I don't see really much more overhead if you add a setting to a group that says: "this groups can only see the users from this group"

Roel Croonenberghs

I don't understand your focus on these email domains. Confluence page/space view/edit restrictions is based on users/groups. No where can you define something based on the email domain. (as far as I know)

It would also make no sense, because if I change my mail adres, that doesn't mean my user rights should change.

Roel Croonenberghs

@Rusty (Matt)Image this: I'm user with email domain "supplier" And my colleague also is on domain "supplier" And we have 4 other users, 2 with domain "customer1" and 2 with domain "customer2". When I login, and did not interact with any of the pages before (or within 90 days). That would mean I don't get to see customer1 or2 and only see my colleague on supplier. If my colleague has edited some page. Then when customer1 logins in, he can only see my colleague, but not me. And after 91 days, suddenly my colleague is gone for customer1 as well.

Is this how the rules would work? If so, that would not be good for what we are using confluence. (I find it unlogic)

If not, can you explain more these rules based on email domain?

Andy

To do with https://community.atlassian.com/t5/Confluence-questions/How-do-I-stop-profile-pictures-showing-up-in-search-to-anonymous/qaq-p/406500 which someone suggested was related to CONFSERVER-1882

Nicola Barton

We face several problems in using Confluence. We want to use Confluence for different clients. So far this has not been feasible because we have strict NDAs with some of them.

The security of Confluence has so far appeared to come across as an afterthought, rather than the starting point, as it should be.

It concerns me that it is not clear when setting up Confluence that privacy settings are set to such a broad level by default and that I found out about these privacy issues by chance, rather than by design.

In my opinion this approach is not compliant with GDPR.

1. User Mentions

Anyone can use the user mention @name function and it will bring up any confluence user in our instance if the right letters are entered. Clients should not be able to see other clients unless we tell the system to do so. Otherwise, we're breaching our NDAs.

A user mention creates a link to user's profile. A user updates their own profile and we don't have the facility to make this secret. Therefore clients that use multiple Confluence instances may have more information in their profile than they unwittingly share on accepting an invitation to join another instance. It needs to be clearer to users on how their profile is used and consent to share profile data with those instances should be granular.

If a user is mentioned, or assigned to a task on a page/space that they don't have access to, no email is triggered, however a link to their profile will still be created. This is misleading to the page viewer and allows the user's profile to be viewable.

2. Page Sharing

When a user shares a page, they can select a username or group.

Selecting by username works with autocomplete so it potentially shows any user in our confluence instance.

Selecting by group works similarly, and the user can select any group in confluence or JIRA. There's the potential for one client to trigger a notification to another client, a whole group of them, or even every user we have.

Atlassian say they have switched off this facility (although it appears I can go through the steps to do this, it's just that no-one receives the page share notification) for our instance but it is not something I can configure at my end and I had to specifically ask for it.

3. People Directory

Atlassian (on request) removed the link to this, but I share the views of Björn Wennerström, and email domain would absolutely not work for us for the same reasons as Roel Croonenberghs and Normand Carbonneau. I support Jim Lynch's suggestion to more easily see who is in a group too.

IntelliDynamics Administrator

I sent you a message / invite to connect on LinkedIn.

Carl Cook
President / CTO
IntelliDynamics

Markus Hääl

Any updates on this topic?

I agree with the above comments. Domains might not work when I have a space with a customer and 2 partners. So 3 different domain names are using the same space but all of them can see only eachother and cannot mention other collaborators in that space?

This should work with Spaces and/or groups. So people can mention and see profiles only of the people in the same group or same space.

As the fore mentioned people also said, we have confidential projects and some customers are competitors, so if they would see we are servicing both they might stop collaboration even. Not to mention the data breach.

Tobias_c77xl0

And another month later: Any update on this topic @Rusty (Matt)?

adrian.wood

Floris ten Hove

Hi,

Are there any updates on this topic? We're in desperate need of restricting access to our Atlassian people directory and Confluence spaces (@mentions).

Josh_wo21i3

Jan Riepshoff

Patrick Heck

Why does this have to be complicated. It should be deterministic and easily controlled and definately not involve time calculations (need I mention the 37 possible timezones, DST, etc involved). Two simple rules would do:

You can see people with whom you share a group.

Administrators see everyone.

Simple. By default everyone sees everyone because of things like jira-users etc, but wherever tighter restrictions are required one can remove that from users, and then it's infinitely tweak-able. There's no magic timing. It doesn't take 90 days for someone you kicked out or fired to be removed... etc.

Rules simply apply everywhere, mentions, issue displays, authors on pages, sharing, people directory etc. Same rule anywhere you go and anywhere a user account is involved. Special cases are an anathema when trying to secure things.

Stupid simple principle. Administrators need arbitrary control over who can see who. The site/org belongs to them. They need to be in control. You can NEVER predict the requirements accurately across all users.

If you loose access to seeing someone they should simply show as "A User" no number, no details nothing to allow you to tell one from another. Add a little help icon that pops up a bubble that says "You are not in the same group as this user and therefore cannot see their user information"

"It's our preference to try and create a set of rules here that require no setup or maintenance, and provide the power of browsing users in mentions and user pickers to all end users."

ARGH don't make your life harder than it is by inventing artificial requirements. The default will be as it is now, anyone sees anyone due to things like users and developers groups, so your first contact for most folks will be "it works" and your first contact for someone who enters with a specific requirement will be "I can do that"

And I very much want to echo this from above:

Clients should not be able to see other clients unless we tell the system to do so. Otherwise, we're breaching our NDAs.

Patrick Heck

Keep in mind that a two divisions of a large company may be separate clients. (even though they are @ the same email domain.

roco

spot on

Patrick Heck

By the way, this does effect your sales. This issue prevented me from moving a client into Jira from trello (which also has issues, in this vein, but was already in place with the client).

Brandon Rioja

All other users on the site who’s email domain matches yours. This excludes a set of known email public email domains like gmail.
The last 30 users you have collaborated with, based on 90 days of activity. Collaboration is defined here as any non-view event (e.g. creating, editing, commenting, liking, watching) on any of the same content.

I don't think either of these features solve the issue that we are having. Can I propose to other stories?

As a CEO of another company, I would like to keep the information that I'm working with your company confidential so that my competitors don't know about upcoming product offerings.

As a CEO, I would like to control the disclosure of companies that we are working with so that this information can be presented to the company when ready and not before that.

As a laywer, I would like to be able to fully comply with Non-disclosure agreements (NDA), so that we can get business.

As you already outlined, the only way to comply with these stories is to completely disable Confluence externally and delete the "view users and groups" global permission. This is unfortunate because we will have to figure out another way to communicate with customers that isn't Confluence.

Guy Anela

We too are facing this same conundrum. Has there been any progress on implementing a solution or identifying a workaround?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-cloud

confluence-cloud

teamwork