Highlighted

Call for feedback - Atlassian cloud people directory user visibility

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.

11 comments

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.

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. 

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'

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. 

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.

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"

@Matthew Russell The email domain is in most cases not a good common denominator. Our company has multiple customers with multiple projects, where 3rd parties form both our side and the customer side are involved. 

Project Alpha

  • john@ourcompany.co
  • emma@clientshop.co
  • danna@designersinc.co
  • mike@seoguys.co 

Project Beta

  • jim@ourcompany.co
  • emil@clientshop.co
  • david@designersin.co
  • mona@seoguys.co

I would expect people on Project Alpha to see each other in an autocomplete list. Same for Project Beta. But people in Project Alpha should not even know there is a Project Beta and never see any of the people in it.

This is a realistic configuration for us, not a theoretical, devil's advocate example.

@Gabriel Radic, your example is also 100% compliant with our needs.

I've had this request from a number of customers (we run an Atlassian Solution Partner company) - can vouch for multiple examples that fit this pattern described by @Gabriel Radic, when external facing collaboration extranet deployments are needed.

Hi @Gabriel Radic - just to be clear, your statement indicates that

  • john@ourcompany.co should not be able to know that jim@ourcompany.co exists, and vice versa.
  • emma@clientshop.co should not be able to know that emil@clientshop.co exists, and vice versa. 
  • danna@designersinc.co should not be able to know that david@designersin.co exists, and vice versa (although I think there's a typo in david's email address?)
  • mike@seoguys.co should not be able to know that mona@seoguys.co exists, and vice versa.

If this is true, I would really like to better understand the why behind this setup, because to me that seems extremely siloed and unusual.

If you can take the time to have a half hour conversation, I'd really appreciate it. Feel free to reach out https://www.linkedin.com/in/matthew-russell-81539510/

Thanks.

Hi Matthew,

yes, that is correct, the users in the same company should not be aware of the projects other are working on until they are part of that project. 

It's not that unusual. We are a software development company working with technology partners, where different groups in different departments work on different projects. Sometimes (most of the time) those projects are confidential.

And to add to @Gabriel Radic comment, this is also our case. We are a consulting company, and we have customers that are competitors. So, it is important that our employees working for Customer A cannot access documentation of Customer B, and our employees working for Customer B cannot see documentation of Customer A either. Doing so would break our NDAs.

As you see, we are using Confluence in a real business environment, and even if the collaborative aspect of Confluence is its core, it cannot just be freely opened to everyone as there is a legal aspect involved.

Hi

I support Normand comment @Normand Carbonneau, @Gabriel Radic. As a software company in Life Sciences research we too have customers that are competitors. Our NDAs demand separation and your product today does not support this. 

I think by now Atlassian need to show action and demonstrate a product worthy of being considered to operate under these constraints.

Hi @Gabriel Radic@Normand Carbonneau@Dave Winter - I want to be clear here that the visibility scope we are discussing is user profiles. Nothing I have proposed is about the permission of content on a site (e.g. project, space, page, issue, etc). Rather it's the ability for someone to see another user's profile. 

Normand, you talk "about employees working for Customer A cannot access documentation of Customer B, and our employees working for Customer B cannot see documentation of Customer A either" Is it a breach of your NDA's for those employee's to know about each other's existence? i.e. can employee working for Customer A be able to see a profile info (name, photo, email, nickname, job title, department, organisation) on employee working for Customer B? No content, just profile info. I should clarify that all work displayed on the user's profile would respect permissions at the content.

It would be great if I could understand that concern better.

Hi @Matthew Russell, I am ok if all our employees can see all profiles, as long as they cannot use a @mention of someone working for Customer B in Confluence documentation of Customer A. As you see, when talking about security, I think we cannot approach it from the point of view of a single feature. We have to look at the entire needs, the interrelations between all components and features, and then make a plan accordingly. If we just look at User Profiles, without considering the different impacts it has, I think we have high chances of missing something else.

Hi @Matthew Russell @Normand Carbonneau @Gabriel Radic

I would also add that a "user profile" can be viewed in the same way as a Page.

A customer should only see the user profiles of those who can read / edit the page.  An  NDA is non-disclosure and this includes names / profiles. 

The emphasis is on security and that of addressing the risk of data leakage.

Regards

Dave  

My use case is similar to @Roel Croonenberghs and @Gabriel Radic. As a freelancer, I want to use confluence for internal purposes, and add spaces for each client/project for external collaboration. If administering the user permissions by group would create a lot of admin overhead, I can accept that because a) I only need to deal with a small number of users and groups at once and b) I am using Confluence Cloud, so the alternative at the moment is separate instances for each client. I have done just that for a few clients, but it creates all sorts of problems when the project ends and I want to shut down the short-term instance and have to import the content back into a 'main' site for archiving. When I say 'a client', I really mean the external user group, which may consist of people from more than one company. As others have said, a common email domain does not define the user group.

For those using Confluence Server, the Space Privacy plugin looks like a great option that's available now.

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.

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 

  

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?

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.

Hi Matthew

Thanks for taking the time to respond - appreciated.

In answer to your question, no that is not quite the case sorry - apologies if I gave that impression.

For viewing the directory I do not see an issue allowing users to see who else in their company that participates in the Confluence cloud they are working in. I would restrict the view to email address only no other personal information. 

You may also wish to have a setting for the user as "Private" which stops their information being viewed in the directory by general user within their company.     

We see the cases where customers can have many divisions and not all divisions will always share information.

Best regards

Dave

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.

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

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

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.

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.

We have employees and multiple corporate customers. Our needs:

  1. 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.
  2. 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

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

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/

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

Carl Cook
President / CTO
IntelliDynamics

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!

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

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.

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.

@Matthew RussellImage 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?

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.

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.

And another month later: Any update on this topic @Matthew Russell?

Comment

Log in or Sign up to comment
Community showcase
Posted Oct 08, 2018 in Teamwork

If you could delete any meeting from your calendar, which one would it be?

Let’s face it: most of us have too many meetings on our calendars. And few things are a bigger waste of time than recurring meetings that no longer provide any value to attendees (or the busines...

567 views 16 9
Join discussion

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