Uploaded image for project: 'Confluence'
  1. Confluence
  2. CONF-7837

People Directory and "controlled" privacy / configure access to People Directory depending on Group membership

    Details

    • Last commented by user?:
      true
    • Support reference count:
      12

      Description

      Requirement:
      Depending on group membership users may (or may not) see users in their own or in other groups in the People Directory.

      Scenario example:

      • Internal people should be able to see all users (from their department and/or project group) as well as all customers that they are responsible for / ideally grouped per company/department/...
      • External users (customers) from company XYZ should be able to see (some) internal users (i.e. those responsible for their project), in addition all users from their own organization (members in the group XYZ) and possibly some users from another company that is utilizing the same product.

      Above could be solved by smart grouping of people, provided that the access to the People Directory is "better" configurable.

      Note: The "Shared Mode" setting in the General Configuration does not solve the issue - this is an all-or-nothing approach, it would be highly desirable to have a fine-grained controlled access to the People Directory in one of the future Confluence releases.

      Atlassian Status as of September 7, 2012

      Hi All,

      Thank you for your feedback on this issue thus far. We acknowledge that many of you are looking bring your customers and other external users into your internal Confluence site and therefore want tighter control over which users can browse the people directory.

      At this stage we do not have a way to control who can browse the people directory. If it is crucial for you to completely hide the people directory from all users, we have instructions on how to disable this in your self-hosted instance. We do know that the people directory is extremely useful and that you still want to make it available for some users, like your internal employees.

      We do hope to provide a solution for this issue in the future but have no immediate plans to do so at this time. We will update the status of this issue once we have made further progress.

      Thank you for your patience.
      Bill Arconati,
      Confluence Product Manager

        Issue Links

          Activity

          Hide
          christopher.owen@atlassian.com Christopher Owen [Atlassian] added a comment -

          Thanks for your suggestion Aleksandar

          Show
          christopher.owen@atlassian.com Christopher Owen [Atlassian] added a comment - Thanks for your suggestion Aleksandar
          Hide
          andrev André Heie Vik added a comment -

          This is also relevant when you enable anonymous access to one or more spaces in Confluence. Currently, anonymous users can see the people directory unless you enable "shared mode" and turn it off alltogether.

          Show
          andrev André Heie Vik added a comment - This is also relevant when you enable anonymous access to one or more spaces in Confluence. Currently, anonymous users can see the people directory unless you enable "shared mode" and turn it off alltogether.
          Hide
          davida David A added a comment -

          We think that allowing anonymous users to see the people directory is a security threat. So we will probably have to disable it by enabling shared mode as described above. This is a pity because its a useful feature for 'real' users.

          Show
          davida David A added a comment - We think that allowing anonymous users to see the people directory is a security threat. So we will probably have to disable it by enabling shared mode as described above. This is a pity because its a useful feature for 'real' users.
          Hide
          berndr Bernd Rinn added a comment -

          We, too, think that showing the people directory to anonymous users is a privacy issue. For us it would be a solution to be able to switch off the people directory without having to switch off email archiving (as is done when we enable "shared mode").

          Show
          berndr Bernd Rinn added a comment - We, too, think that showing the people directory to anonymous users is a privacy issue. For us it would be a solution to be able to switch off the people directory without having to switch off email archiving (as is done when we enable "shared mode").
          Hide
          tom@atlassian.com Tom Davies [Atlassian] added a comment -

          'Shared Mode' was meant to be used only for Hosted Confluence installations. The Shared Mode setting has been removed in Confluence 2.5.1.

          For Confluence 2.5.2 we have added two system properties to control access to the people directory:

          -Dconfluence.disable.peopledirectory.anonymous=true – disable the people directory for anonymous users.
          -Dconfluence.disable.peopledirectory.all=true – disable the people directory entirely.

          Note that the link will still appear on the dashboard, so you will need to modify the global.vmd file to remove the link.

          I will leave this issue open, as more flexible permission settings for the people directory would be nice.

          Show
          tom@atlassian.com Tom Davies [Atlassian] added a comment - 'Shared Mode' was meant to be used only for Hosted Confluence installations. The Shared Mode setting has been removed in Confluence 2.5.1. For Confluence 2.5.2 we have added two system properties to control access to the people directory: -Dconfluence.disable.peopledirectory.anonymous=true – disable the people directory for anonymous users. -Dconfluence.disable.peopledirectory.all=true – disable the people directory entirely. Note that the link will still appear on the dashboard, so you will need to modify the global.vmd file to remove the link. I will leave this issue open, as more flexible permission settings for the people directory would be nice.
          Hide
          davida David A added a comment -

          Tom, thanks for the update - this is good news. When will 2.5.2 be released?

          Show
          davida David A added a comment - Tom, thanks for the update - this is good news. When will 2.5.2 be released?
          Hide
          tom@atlassian.com Tom Davies [Atlassian] added a comment -

          2.5.2 will be released this week.

          Show
          tom@atlassian.com Tom Davies [Atlassian] added a comment - 2.5.2 will be released this week.
          Hide
          andrev André Heie Vik added a comment -

          The system property works, but username/profile links still show up in the "Recently updated" list for anonymous users whenever a user profile is updated.

          Show
          andrev André Heie Vik added a comment - The system property works, but username/profile links still show up in the "Recently updated" list for anonymous users whenever a user profile is updated.
          Hide
          wiik Thorleif Wiik added a comment -

          It would be great to have a "people directory on/off" button in the admin gui which should be
          the same as -Dconfluence.disable.peopledirectory.all=true

          Show
          wiik Thorleif Wiik added a comment - It would be great to have a "people directory on/off" button in the admin gui which should be the same as -Dconfluence.disable.peopledirectory.all=true
          Hide
          padawan François Nonnenmacher added a comment -

          André, I've reported that as a bug, which it is to me, see: CONF-9438.

          Show
          padawan François Nonnenmacher added a comment - André, I've reported that as a bug, which it is to me, see: CONF-9438 .
          Hide
          laguest Larry Guest added a comment -

          I need to remove the people directory since I cant limit who can see users.
          I added "-Dconfluence.disable.peopledirectory.all=true " to my setenv.sh under JAVA_OPT

          When I restarted the app I could no longer see any of my Active Directory groups. Also the only logins that would work are local ones. Seems it may have broken my link to AD?

          Show
          laguest Larry Guest added a comment - I need to remove the people directory since I cant limit who can see users. I added "-Dconfluence.disable.peopledirectory.all=true " to my setenv.sh under JAVA_OPT When I restarted the app I could no longer see any of my Active Directory groups. Also the only logins that would work are local ones. Seems it may have broken my link to AD?
          Hide
          matt@atlassian.com Matt Ryall [Atlassian] added a comment -

          Larry, this option should not affect your LDAP configuration at all. Please raise a support request at https://support.atlassian.com, and attach your logs. Our support team will be able to help you resolve this problem.

          Show
          matt@atlassian.com Matt Ryall [Atlassian] added a comment - Larry, this option should not affect your LDAP configuration at all. Please raise a support request at https://support.atlassian.com , and attach your logs. Our support team will be able to help you resolve this problem.
          Hide
          laguest Larry Guest added a comment -

          Any update on when and if this be included into a release?

          We really want to be able to use personal spaces but cant since anyone can see them.

          FYI. It did not affect my AD as reported above, must have been user error on my side this first time I tried the work around.

          Show
          laguest Larry Guest added a comment - Any update on when and if this be included into a release? We really want to be able to use personal spaces but cant since anyone can see them. FYI. It did not affect my AD as reported above, must have been user error on my side this first time I tried the work around.
          Hide
          rcroonenberghs Roel Croonenberghs added a comment -

          It would be great to be able to define which groups can see the people directory.
          ex (disable access for group1 group 3 and group8)
          -Dconfluence.disable.peopledirectory.group1=true
          -Dconfluence.disable.peopledirectory.group3=true
          -Dconfluence.disable.peopledirectory.group8=true

          Via command line or maybe via admin page of people directory (treat it as a space)

          Show
          rcroonenberghs Roel Croonenberghs added a comment - It would be great to be able to define which groups can see the people directory. ex (disable access for group1 group 3 and group8) -Dconfluence.disable.peopledirectory.group1=true -Dconfluence.disable.peopledirectory.group3=true -Dconfluence.disable.peopledirectory.group8=true Via command line or maybe via admin page of people directory (treat it as a space)
          Hide
          albertwu Albert added a comment -

          In identity management, we believe that the individual should ultimately have control over the release of her personal data. Whether a person is listed in a searchable directory really should be an option that the individual user makes. Of course, the site admin should be able to set a default release preference.

          Show
          albertwu Albert added a comment - In identity management, we believe that the individual should ultimately have control over the release of her personal data. Whether a person is listed in a searchable directory really should be an option that the individual user makes. Of course, the site admin should be able to set a default release preference.
          Hide
          padawan François Nonnenmacher added a comment -

          Albert, while I do understand that on a personal level, it doesn't pass a simple reality check: within many companies this is a sensitive HR issue and not something you can deal with by saying it's up to each individual to decide.

          So far, for my clients, the only solution today is to hack Confluence to disable the whole directory for everybody, so long for choices!

          Show
          padawan François Nonnenmacher added a comment - Albert, while I do understand that on a personal level, it doesn't pass a simple reality check: within many companies this is a sensitive HR issue and not something you can deal with by saying it's up to each individual to decide. So far, for my clients, the only solution today is to hack Confluence to disable the whole directory for everybody, so long for choices!
          Hide
          kcoco Kristine Coco added a comment -

          I would like to set access to the People Directory based on user groups. Here is the specific scenerio I am trying to accomodate. My internal team works with various external teams who do not work with each other. I do not want external users being able to see other external users. It's a privacy violation of our agreements with them.

          My only option right now is to remove the People Directory for all users, which is sub-optimal. I would much rather allow internal users to see the people directory.

          My suggestion is to add a new permission you can choose under the "Global Permissions" page in the Admin panel. This would at least allow users to manage access per group, though it wouldn't allow for more fine grained permissioning for access to particular profiles.

          Show
          kcoco Kristine Coco added a comment - I would like to set access to the People Directory based on user groups. Here is the specific scenerio I am trying to accomodate. My internal team works with various external teams who do not work with each other. I do not want external users being able to see other external users. It's a privacy violation of our agreements with them. My only option right now is to remove the People Directory for all users, which is sub-optimal. I would much rather allow internal users to see the people directory. My suggestion is to add a new permission you can choose under the "Global Permissions" page in the Admin panel. This would at least allow users to manage access per group, though it wouldn't allow for more fine grained permissioning for access to particular profiles.
          Hide
          aeng Audra Eng [Atlassian] added a comment -

          This is a nice feature to have, we will consider it for the long term roadmap.

          If you're interested to know how we decide on which features to implement, please read this:
          http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements

          Show
          aeng Audra Eng [Atlassian] added a comment - This is a nice feature to have, we will consider it for the long term roadmap. If you're interested to know how we decide on which features to implement, please read this: http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements
          Hide
          ldyer Lisa Dyer added a comment -

          I second the requirement as Kristine describes it. This is not just a nice feature. Many corporations consider the ability to provide secure microsites with rich information for their customers a paramount business requirement, and will look elsewhere if Atlassian products cannot support that. Does anyone know if there are any Atlassian partners working on this problem?

          Show
          ldyer Lisa Dyer added a comment - I second the requirement as Kristine describes it. This is not just a nice feature. Many corporations consider the ability to provide secure microsites with rich information for their customers a paramount business requirement, and will look elsewhere if Atlassian products cannot support that. Does anyone know if there are any Atlassian partners working on this problem?
          Hide
          bmaloney@ravenglass.com Bridget added a comment -

          I agree, group filtering would be great in the people directory!

          Optimally, there would be a setting in the user profile that allowed us to set if that user can only see users that belong to the same groups.

          I really hope something comes of this issue soon!

          Show
          bmaloney@ravenglass.com Bridget added a comment - I agree, group filtering would be great in the people directory! Optimally, there would be a setting in the user profile that allowed us to set if that user can only see users that belong to the same groups. I really hope something comes of this issue soon!
          Hide
          mcboof Jon Marks added a comment - - edited

          Same boat here. We have many spaces that we use to share work with clients. We want the people directory to be internal only. It only shows internel people (preferably), and only internal people can see it (a must have before we turn it on). A simple "People Directory only visible to Group X" would be a great start for us.

          Show
          mcboof Jon Marks added a comment - - edited Same boat here. We have many spaces that we use to share work with clients. We want the people directory to be internal only. It only shows internel people (preferably), and only internal people can see it (a must have before we turn it on). A simple "People Directory only visible to Group X" would be a great start for us.
          Hide
          bmaloney@ravenglass.com Bridget added a comment -

          I would love to see this feature - an option to only allow users to see other users in the People Directory if they belong to the same groups.

          Is there anything I can do to get this feature off the ground?

          Thanks,
          Bridget

          Show
          bmaloney@ravenglass.com Bridget added a comment - I would love to see this feature - an option to only allow users to see other users in the People Directory if they belong to the same groups. Is there anything I can do to get this feature off the ground? Thanks, Bridget
          Hide
          admin@ardas.dp.ua Alexey Chernysh added a comment -

          I would like to see this option in next releases

          Show
          admin@ardas.dp.ua Alexey Chernysh added a comment - I would like to see this option in next releases
          Hide
          jhill@erb-erb.com Jono Hill added a comment -

          This would be great for any number of reasons, the biggest of which is obviously privacy for clients. Hopefully it's available soon.

          Show
          jhill@erb-erb.com Jono Hill added a comment - This would be great for any number of reasons, the biggest of which is obviously privacy for clients. Hopefully it's available soon.
          Hide
          swherdman Scott Herdman added a comment -

          there is this plug in but it doesn't look like its out yet, sound like its exactly what i need and what i think confluence needs, even if just initially its just a function to let me limit personal spaces and People directory to just one group. Until then i just have to continue to disable them

          http://confluence.atlassian.com/display/CODEGEIST/Confluence+PeopleDirectoryAccessControl+Plugin

          Show
          swherdman Scott Herdman added a comment - there is this plug in but it doesn't look like its out yet, sound like its exactly what i need and what i think confluence needs, even if just initially its just a function to let me limit personal spaces and People directory to just one group. Until then i just have to continue to disable them http://confluence.atlassian.com/display/CODEGEIST/Confluence+PeopleDirectoryAccessControl+Plugin
          Hide
          cmonkus Clay Monkus added a comment -

          I share Kristine's view. I would also like to set access to the People Directory based on user groups.

          Show
          cmonkus Clay Monkus added a comment - I share Kristine's view. I would also like to set access to the People Directory based on user groups.
          Hide
          helenne Helen Newham added a comment -

          Totally agree - would love to see groups-based access on the People Directory.

          Access control to person-based information is becoming increasingly important and sensitive in my company.

          Show
          helenne Helen Newham added a comment - Totally agree - would love to see groups-based access on the People Directory. Access control to person-based information is becoming increasingly important and sensitive in my company.
          Hide
          spark9@csc.com Sung Park added a comment -

          Confluence has good Access Control on many items. I believe this is another piece missing which needs to be address as soon as possible. With large user base, its critical to control what each person can see and not see.

          Come on Atlassian... you can do it!!

          Show
          spark9@csc.com Sung Park added a comment - Confluence has good Access Control on many items. I believe this is another piece missing which needs to be address as soon as possible. With large user base, its critical to control what each person can see and not see. Come on Atlassian... you can do it!!
          Hide
          dwhite75@csc.com Dionne White added a comment -

          This functionality is greatly needed in our environment and apparently greatly needed by many others. We are in competition with a similar application within our company but access control is the one area where Confluence sticks out and rises above. Help us out by addressing this issue!

          Show
          dwhite75@csc.com Dionne White added a comment - This functionality is greatly needed in our environment and apparently greatly needed by many others. We are in competition with a similar application within our company but access control is the one area where Confluence sticks out and rises above. Help us out by addressing this issue!
          Hide
          raphaeljoss Raphael Joss added a comment -

          We would like to have this implemented.

          We implement Confluence for customers as a Intranet or Extranet solution. For Extranet Use Case this is a real issue. Why should one be able to hide content from each other but not user information.
          In Extranet Use Cases companies work together with their clients or suppliers and they should be able to hide every information about these projects including the users working on it.
          With People Directory, search or the user list macro, every user is capable to find out with which clients or suppliers a company works, which for some companies is a major security issue.

          So without this feature we can't really recommend Confluence as an Extranet solution.

          Show
          raphaeljoss Raphael Joss added a comment - We would like to have this implemented. We implement Confluence for customers as a Intranet or Extranet solution. For Extranet Use Case this is a real issue. Why should one be able to hide content from each other but not user information. In Extranet Use Cases companies work together with their clients or suppliers and they should be able to hide every information about these projects including the users working on it. With People Directory, search or the user list macro, every user is capable to find out with which clients or suppliers a company works, which for some companies is a major security issue. So without this feature we can't really recommend Confluence as an Extranet solution.
          Hide
          blakeburdeen Blake Burdeen [HTTP Factory] added a comment -

          For us it isnt a security issue - we allow access internally only...

          There is - however - the situation where you have legacy users that are no longer in the confluence-users group (and are no longer even with the company!) and it really doesn't make sense to clutter up a great directory with "old" contributors...

          Right now the workaround of disabling the menu item is OK - but that means that we have to manually maintain our own listing/ directory...

          We've got to be getting close to enough votes and feedback to get this addressed - it's been an issue I've seen since 2006 (when we first moved to Confluence) and this issue has been open since 2007...

          Show
          blakeburdeen Blake Burdeen [HTTP Factory] added a comment - For us it isnt a security issue - we allow access internally only... There is - however - the situation where you have legacy users that are no longer in the confluence-users group (and are no longer even with the company!) and it really doesn't make sense to clutter up a great directory with "old" contributors... Right now the workaround of disabling the menu item is OK - but that means that we have to manually maintain our own listing/ directory... We've got to be getting close to enough votes and feedback to get this addressed - it's been an issue I've seen since 2006 (when we first moved to Confluence) and this issue has been open since 2007...
          Hide
          tmoore Tim Moore [Atlassian] added a comment -
          Show
          tmoore Tim Moore [Atlassian] added a comment - Related JIRA Studio issue: https://studio.atlassian.com/browse/JST-5176
          Hide
          kiki_strauss Kiki Strauss added a comment - - edited

          On a related note, it would be very helpful to be able to filter out individuals from display on the People Directory. My company's mgmt team doesn't want to see ex-employees on the People Directory! Maybe a filter for inactivated profiles? Given the dynamics of our work environment, with individuals coming & going from one company to another, it seems to make sense to support reality.

          Show
          kiki_strauss Kiki Strauss added a comment - - edited On a related note, it would be very helpful to be able to filter out individuals from display on the People Directory. My company's mgmt team doesn't want to see ex-employees on the People Directory! Maybe a filter for inactivated profiles? Given the dynamics of our work environment, with individuals coming & going from one company to another, it seems to make sense to support reality.
          Hide
          emidttun Eirik Midttun added a comment - - edited

          I have the same issue in my company (R&D services) and it is actually preventing us to share spaces with customers. The only solution at the moment is to disable it completely. We don't want to give the customers full access to employee data, only space content for the project they give us.

          EDIT: To be specific, the main problem is a customer being able to see another customer who is (potentially) a competitor.

          Show
          emidttun Eirik Midttun added a comment - - edited I have the same issue in my company (R&D services) and it is actually preventing us to share spaces with customers. The only solution at the moment is to disable it completely. We don't want to give the customers full access to employee data, only space content for the project they give us. EDIT: To be specific, the main problem is a customer being able to see another customer who is (potentially) a competitor.
          Hide
          emidttun Eirik Midttun added a comment -

          And status updates seems to be visible to anyone. Would be nice to keep them under control.

          Show
          emidttun Eirik Midttun added a comment - And status updates seems to be visible to anyone. Would be nice to keep them under control.
          Hide
          atreadway Ashton Treadway added a comment -

          We have a need for this as well; we want to limit not only who can view what information in the directory, but who shows up in it.

          Show
          atreadway Ashton Treadway added a comment - We have a need for this as well; we want to limit not only who can view what information in the directory, but who shows up in it.
          Hide
          barconati Bill Arconati added a comment -

          added PM update

          Show
          barconati Bill Arconati added a comment - added PM update
          Hide
          rgamble Ric gamble added a comment -

          we are trying to build a staff directory, however as we cannot delete users who have contributed to confluence it is showing all users including disabled ones.

          It would be great if we could filter the display by group.

          Show
          rgamble Ric gamble added a comment - we are trying to build a staff directory, however as we cannot delete users who have contributed to confluence it is showing all users including disabled ones. It would be great if we could filter the display by group.
          Hide
          jmasson@atlassian.com John Masson added a comment -

          Ric gamble I think CONF-16477, delivered in Confluence 4.3.3, should solve that problem for you.

          Show
          jmasson@atlassian.com John Masson added a comment - Ric gamble I think CONF-16477 , delivered in Confluence 4.3.3, should solve that problem for you.
          Hide
          bbailey@tabula.com Bill Bailey added a comment -

          This is really a must-have for external servers.

          Show
          bbailey@tabula.com Bill Bailey added a comment - This is really a must-have for external servers.
          Hide
          abaru Alex Baru added a comment -

          This is a must have feature for us as well. Very frustrating not to be able to setup an extranet space in confluence.

          Show
          abaru Alex Baru added a comment - This is a must have feature for us as well. Very frustrating not to be able to setup an extranet space in confluence.
          Hide
          ldp Laurent Di Pasquale added a comment -

          This is a must have as well for us. We are now reconsidering the use of confluence for our customer documentation database.
          We removed people Directory but still usernames are popping from search box results...

          I don't fully understand why similar requests have no solution yet:

          At least I would like to know how to do this the best way, eventually who to contract to get this implemented. The whole customer business cannot use Confluence if customer users can see each others!

          Show
          ldp Laurent Di Pasquale added a comment - This is a must have as well for us. We are now reconsidering the use of confluence for our customer documentation database. We removed people Directory but still usernames are popping from search box results... I don't fully understand why similar requests have no solution yet: Shared mode is disabled since a very old version: can't Atlassian re-enable it? No instructions to modify searchResult indexes to remove user info from there (seems a WA is available as mentioned there: https://jira.atlassian.com/browse/CONF-21952 but solution in https://support.atlassian.com/browse/CSP-58347 is not displayed to others...) At least I would like to know how to do this the best way, eventually who to contract to get this implemented. The whole customer business cannot use Confluence if customer users can see each others!
          Hide
          marcel_h Marcel Hungerbühler added a comment - - edited

          This is a Must-have feature for Confluence on demand. I must have the option to disable certain groups of customers in the people directory, so that they don't see each other. This is a crucial feature!

          Show
          marcel_h Marcel Hungerbühler added a comment - - edited This is a Must-have feature for Confluence on demand. I must have the option to disable certain groups of customers in the people directory, so that they don't see each other. This is a crucial feature!
          Hide
          kontakt1 Benjamin Wolf added a comment -

          It's also an essential requirement in our company. We need this feature to make Confluence accessible to our customers.

          Show
          kontakt1 Benjamin Wolf added a comment - It's also an essential requirement in our company. We need this feature to make Confluence accessible to our customers.
          Hide
          j.yatchak Julie Yatchak added a comment - - edited

          If I can't hide external users from the People Directory, I will not be able to use this product. I have seen people who are using the OnDemand version of Confluence have been asking for this for some time now. Please provide some type of solution.

          Show
          j.yatchak Julie Yatchak added a comment - - edited If I can't hide external users from the People Directory, I will not be able to use this product. I have seen people who are using the OnDemand version of Confluence have been asking for this for some time now. Please provide some type of solution.
          Hide
          office21 office account added a comment -

          This has been known since 07 and is still not fixed? This is a huge issue for ondemand service providers with multiple clients.

          Show
          office21 office account added a comment - This has been known since 07 and is still not fixed? This is a huge issue for ondemand service providers with multiple clients.
          Hide
          s.mehl Sebastian Mehl added a comment -

          Same here, hiding the People Directory is essential for our company. People also shouldn't pop up in search bar or in @mentions except they are assigned to the same group. Otherwise we'll have a huge privacy/security issue. There are still no plans for adding such a functionality in OnDemand?

          Show
          s.mehl Sebastian Mehl added a comment - Same here, hiding the People Directory is essential for our company. People also shouldn't pop up in search bar or in @mentions except they are assigned to the same group. Otherwise we'll have a huge privacy/security issue. There are still no plans for adding such a functionality in OnDemand?
          Hide
          david.bullock@machaira.com.au David Bullock added a comment -

          My thoughts are that the People Directory has value, but there just needs to be some control over 'who can see who'. It is obviously a disadvantage to disable it altogether.

          My request is therefore that a user can see in the People Directory only those users with whom they share a 'group' in common. To be useful, the mandatory (in my experience) 'users' group would not qualify for the 'has groups in common' check. It may also be of benefit to give the Confluence admin the opportunity to exclude other groups from the check.

          Show
          david.bullock@machaira.com.au David Bullock added a comment - My thoughts are that the People Directory has value, but there just needs to be some control over 'who can see who'. It is obviously a disadvantage to disable it altogether. My request is therefore that a user can see in the People Directory only those users with whom they share a 'group' in common . To be useful, the mandatory (in my experience) 'users' group would not qualify for the 'has groups in common' check. It may also be of benefit to give the Confluence admin the opportunity to exclude other groups from the check.
          Hide
          atlassian6 François Nonnenmacher added a comment - - edited

          @David Bullock: it would be much simpler to add a column "Can view the People Directory" to the global permissions, similar to how you allow groups to access other general parts of the Confluence instance.

          Show
          atlassian6 François Nonnenmacher added a comment - - edited @David Bullock: it would be much simpler to add a column "Can view the People Directory" to the global permissions, similar to how you allow groups to access other general parts of the Confluence instance.
          Hide
          david.bullock@machaira.com.au David Bullock added a comment -

          @François: That wouldn't meet my needs, exactly. Our Confluence/JIRA provides a collaborative space between our staff and each of our clients. We definitely don't want staff from Client A being able to see the staff from Client B in the people directory.(unless there was a good reason for it). We don't mind so much if clients can see our staff ... especially those staff which are active in projects/spaces to which the client has been invited. And we don't much mind if staff of Client A can see their own staff. And we don't much mind if our staff can see the staff of all clients, although they probably don't need to know about clients who aren't in spaces/projects they are also in.

          A 'Can view the people directory' attribute doesn't suffice in the above case. It's too all or nothing.

          My 'group based' idea might not hit the mark exactly. It would probably be more in-keeping with the philosophy of the product(s) if users could only see users who have privileges to projects and spaces in common. This is much the same thing that happens with the 'activity stream' anyway. There might be some reason to have 'uber-public' users ... these could get a 'display me in the group directory always' flag on their user profile.

          Show
          david.bullock@machaira.com.au David Bullock added a comment - @François: That wouldn't meet my needs, exactly. Our Confluence/JIRA provides a collaborative space between our staff and each of our clients. We definitely don't want staff from Client A being able to see the staff from Client B in the people directory.(unless there was a good reason for it). We don't mind so much if clients can see our staff ... especially those staff which are active in projects/spaces to which the client has been invited. And we don't much mind if staff of Client A can see their own staff. And we don't much mind if our staff can see the staff of all clients, although they probably don't need to know about clients who aren't in spaces/projects they are also in. A 'Can view the people directory' attribute doesn't suffice in the above case. It's too all or nothing. My 'group based' idea might not hit the mark exactly. It would probably be more in-keeping with the philosophy of the product(s) if users could only see users who have privileges to projects and spaces in common. This is much the same thing that happens with the 'activity stream' anyway. There might be some reason to have 'uber-public' users ... these could get a 'display me in the group directory always' flag on their user profile.
          Hide
          rcroonenberghs Roel Croonenberghs added a comment -

          I totally agree, whe have the same issues. different clients, and we dont want our clients to see the users from other clients. But everybody can see our staff.
          I wonder why this takes so long to fix/provide.

          Show
          rcroonenberghs Roel Croonenberghs added a comment - I totally agree, whe have the same issues. different clients, and we dont want our clients to see the users from other clients. But everybody can see our staff. I wonder why this takes so long to fix/provide.
          Hide
          irodrigues Igor Rodrigues added a comment -

          This is ridiculous. We would have to get an instance for each partners/clients/vendors, we can't collaborate properly at all. This is a big issue in our company now. And it's very annoying and I believe it wouldn't take much effort to implement something in Global Permissions like done in JIRA. Very unprofessional indeed.

          Show
          irodrigues Igor Rodrigues added a comment - This is ridiculous. We would have to get an instance for each partners/clients/vendors, we can't collaborate properly at all. This is a big issue in our company now. And it's very annoying and I believe it wouldn't take much effort to implement something in Global Permissions like done in JIRA. Very unprofessional indeed.
          Hide
          matt13 Matt added a comment -

          Very serious limitation of the product. We've had to hobble our entire JIRA/Confluence system by disabling the people directory (no more @mentions for anyone), in order to patch this security hole.

          This isn't a feature request, Atlassian, it's a security issue for most Enterprise users. One that new Atlassian customers should be notified of. We almost found out about it the hard way, by having two (competing) customers see each other in the directory. Could have been a very serious revenue threat if I hadn't stumbled across it first.

          Hopefully someone in Atlassian eventually sees this as the issue it is.

          Show
          matt13 Matt added a comment - Very serious limitation of the product. We've had to hobble our entire JIRA/Confluence system by disabling the people directory (no more @mentions for anyone), in order to patch this security hole. This isn't a feature request, Atlassian, it's a security issue for most Enterprise users. One that new Atlassian customers should be notified of. We almost found out about it the hard way, by having two (competing) customers see each other in the directory. Could have been a very serious revenue threat if I hadn't stumbled across it first. Hopefully someone in Atlassian eventually sees this as the issue it is.
          Hide
          irodrigues Igor Rodrigues added a comment - - edited

          Looks like Atlassian is going to push resolution for this by either new paid plugin (!!!) or no less than next semester. Not without mention that this issue is present in CONFLUENCE for a very long time already - IT WAS RAISED IN FEB-2007. Outrageous.

          Look what can be achieved due to this issue:

          https://confluence.atlassian.com/browsepeople.action?startIndex=

          Show
          irodrigues Igor Rodrigues added a comment - - edited Looks like Atlassian is going to push resolution for this by either new paid plugin (!!!) or no less than next semester. Not without mention that this issue is present in CONFLUENCE for a very long time already - IT WAS RAISED IN FEB-2007 . Outrageous. Look what can be achieved due to this issue: https://confluence.atlassian.com/browsepeople.action?startIndex=
          Hide
          rdwesterbur Ross Westerbur added a comment -

          This is a garden-path deal-breaker for OnDemand. Everything in JIRA and Confluence is consistent with supporting tight controls over access to content, and so it's natural to assume that those controls would not be undermined by any artificial limitations. But this issue, in spite of all of the powerful and flexible tools for steering eyeballs in the right direction, renders Confluence OnDemand completely inappropriate as an option for any firm wanting to provide access to users outside of its list of direct employees. It is one little irritant that is entirely inconsistent with the overall Confluence permissions model - but when it comes to permissions, one little irritant is all it takes to render the whole thing pointless.

          Show
          rdwesterbur Ross Westerbur added a comment - This is a garden-path deal-breaker for OnDemand. Everything in JIRA and Confluence is consistent with supporting tight controls over access to content, and so it's natural to assume that those controls would not be undermined by any artificial limitations. But this issue, in spite of all of the powerful and flexible tools for steering eyeballs in the right direction, renders Confluence OnDemand completely inappropriate as an option for any firm wanting to provide access to users outside of its list of direct employees. It is one little irritant that is entirely inconsistent with the overall Confluence permissions model - but when it comes to permissions, one little irritant is all it takes to render the whole thing pointless.
          Hide
          irodrigues Igor Rodrigues added a comment -

          @Rossa Westerbur, that same issue is faced on Download version - our's company case. It is simply a nightmare.

          Show
          irodrigues Igor Rodrigues added a comment - @Rossa Westerbur, that same issue is faced on Download version - our's company case. It is simply a nightmare.
          Hide
          matthias.jupe Matthias Jupe added a comment -

          We use confluence in a Live-Test-Environment for only one customer. So I found this security hole, too.
          For the People Directory I found a workaround for the Tomcat settings .

          But there is a second Back-door,
          when a customer create a page on confluence he can restricted the page and in this search screen the customer can use Wildcard and now he can saw all users again.

          I disadvised confluence in our company for more than one customer, as long as this Issue won't fixed.

          Show
          matthias.jupe Matthias Jupe added a comment - We use confluence in a Live-Test-Environment for only one customer. So I found this security hole, too. For the People Directory I found a workaround for the Tomcat settings . But there is a second Back-door, when a customer create a page on confluence he can restricted the page and in this search screen the customer can use Wildcard and now he can saw all users again. I disadvised confluence in our company for more than one customer, as long as this Issue won't fixed.
          Hide
          todd12 Todd Simmons added a comment -

          Given the last official comment was September 2012, it would be nice to get an update on whether On Demand customers could anticipate any resolution to this in the near term.

          Show
          todd12 Todd Simmons added a comment - Given the last official comment was September 2012, it would be nice to get an update on whether On Demand customers could anticipate any resolution to this in the near term.
          Hide
          matthias.jupe Matthias Jupe added a comment -

          Update to my Comment from 27/Nov/13 9:37 AM:

          I found a solution for the Back-door, you can configure the external Permissions. Under Space Permissions is a point Pages - Restrict, when the customer can't restrict a page he can't search for all People with Wildcards.

          I don't know why I didn't saw this before.

          Show
          matthias.jupe Matthias Jupe added a comment - Update to my Comment from 27/Nov/13 9:37 AM: I found a solution for the Back-door, you can configure the external Permissions. Under Space Permissions is a point Pages - Restrict , when the customer can't restrict a page he can't search for all People with Wildcards. I don't know why I didn't saw this before.
          Hide
          irodrigues Igor Rodrigues added a comment -

          Mathias, that does not do the trick, FYI. There a number of ways of finding individuals from other vendors/projects and yes the user will still be able to search for people by guessing their names or in case of a person with similar/equal name of anyone in his group/projects - not without mention words that can match any name entirely or partially.

          Show
          irodrigues Igor Rodrigues added a comment - Mathias, that does not do the trick, FYI. There a number of ways of finding individuals from other vendors/projects and yes the user will still be able to search for people by guessing their names or in case of a person with similar/equal name of anyone in his group/projects - not without mention words that can match any name entirely or partially.
          Hide
          dlavelle Dewayne Lavelle added a comment -

          We just noticed this today and are facing the same security hole. Our OnDemand instance is running for several customers and it looks like everyone can see everyones email and contact information under the PEOPLE section. We need a resolution ASAP or we will be discontinuing the use of our OnDemand license.

          Show
          dlavelle Dewayne Lavelle added a comment - We just noticed this today and are facing the same security hole. Our OnDemand instance is running for several customers and it looks like everyone can see everyones email and contact information under the PEOPLE section. We need a resolution ASAP or we will be discontinuing the use of our OnDemand license.
          Hide
          rdwesterbur Ross Westerbur added a comment -

          @Dewayne, FYI, even though you can't configure this directly in OnDemand, you can request that Atlassian turn off the "People" tab in your OnDemand instance via a support request. In my experience this change was put in place by Atlassian support very quickly.

          You can also set "User email visibility" to "only visible to site administrators" in the Confluence Admin > Security Configuration section, which hides email addresses when you mouseover a user link.

          This is not a perfect solution obviously, since it disables some otherwise nice features that ideally would have finer-grained configurability. And the "only visible to site administrators" setting is pretty klunky - you just see the word "hidden" where you would otherwise see an email address, with no clear context. And, it also leaves one potentially problematic fact in that all users still show up in the auto-complete via user mentions. You can also request that Atlassian support turn off user mentions entirely...although in my case that much loss of functionality was not worth the slight gain in privacy, so I compromised on that point. Hope this helps your current situation.

          Show
          rdwesterbur Ross Westerbur added a comment - @Dewayne, FYI, even though you can't configure this directly in OnDemand, you can request that Atlassian turn off the "People" tab in your OnDemand instance via a support request. In my experience this change was put in place by Atlassian support very quickly. You can also set "User email visibility" to "only visible to site administrators" in the Confluence Admin > Security Configuration section, which hides email addresses when you mouseover a user link. This is not a perfect solution obviously, since it disables some otherwise nice features that ideally would have finer-grained configurability. And the "only visible to site administrators" setting is pretty klunky - you just see the word "hidden" where you would otherwise see an email address, with no clear context. And, it also leaves one potentially problematic fact in that all users still show up in the auto-complete via user mentions. You can also request that Atlassian support turn off user mentions entirely...although in my case that much loss of functionality was not worth the slight gain in privacy, so I compromised on that point. Hope this helps your current situation.
          Hide
          dlavelle Dewayne Lavelle added a comment -

          @Ross , thanks for your reply. That does work but only partially. This hides people from Anonymous viewers but if you have an account you can still see people. Also, you can hide the users email address but if they add other data into their profile like phone number and location that cannot be hidden. We believe users should not be able to see each other unless they are part of the same group. This is a huge need for us and will probably be the difference in us continuing with our license or not. So I vote yes!

          Show
          dlavelle Dewayne Lavelle added a comment - @Ross , thanks for your reply. That does work but only partially. This hides people from Anonymous viewers but if you have an account you can still see people. Also, you can hide the users email address but if they add other data into their profile like phone number and location that cannot be hidden. We believe users should not be able to see each other unless they are part of the same group. This is a huge need for us and will probably be the difference in us continuing with our license or not. So I vote yes!
          Hide
          anthony.hill Anthony Hill added a comment -

          I would love to see the ability to control access to the People Directory through the UI. I am the Technical Engineer for Litigation Document Review and the ability for Users to see only the people in there project is critical. I am going to try and do the workaround to turn this feature completely off as the ability to see other users in other projects could be a liability issue. I also agree that this feature should not be turned on by default for Anonymous viewers.

          Show
          anthony.hill Anthony Hill added a comment - I would love to see the ability to control access to the People Directory through the UI. I am the Technical Engineer for Litigation Document Review and the ability for Users to see only the people in there project is critical. I am going to try and do the workaround to turn this feature completely off as the ability to see other users in other projects could be a liability issue. I also agree that this feature should not be turned on by default for Anonymous viewers.
          Hide
          hans-peter.geier Hans-Peter Geier added a comment -

          The issue has become more severe in Confluence 5, as the "people" button has higher visibility than in Confluence 2...3...4.
          Also, for large sites it is potentially creating high system load when users "play" with this button. (large query result)

          Atlassian should finally work on this request!

          Show
          hans-peter.geier Hans-Peter Geier added a comment - The issue has become more severe in Confluence 5, as the "people" button has higher visibility than in Confluence 2...3...4. Also, for large sites it is potentially creating high system load when users "play" with this button. (large query result) Atlassian should finally work on this request!
          Hide
          sean.au Sean Au added a comment -

          Please note that when the "people" button is turned off, (support can do this for you) then the user list macro doesn't work which means you can't show managers how many users you have in confluence and who they are. Admins need to log in and take a screenshot.

          Show
          sean.au Sean Au added a comment - Please note that when the "people" button is turned off, (support can do this for you) then the user list macro doesn't work which means you can't show managers how many users you have in confluence and who they are. Admins need to log in and take a screenshot.
          Hide
          haafiz Haafiz Dossa added a comment -

          I would imagine your internal stats would show that Confluence is quite often used by your clients for both internal and external users within the same instance. Given that, why has this issue and security risk still not been worked on in the OnDemand instances since 2007!?

          Show
          haafiz Haafiz Dossa added a comment - I would imagine your internal stats would show that Confluence is quite often used by your clients for both internal and external users within the same instance. Given that, why has this issue and security risk still not been worked on in the OnDemand instances since 2007!?
          Hide
          kaspar Kaspar Lüthi added a comment -

          Also waiting for this to happen since a very long time.

          Show
          kaspar Kaspar Lüthi added a comment - Also waiting for this to happen since a very long time.
          Hide
          hackl Korbinian Hackl added a comment -

          Need this feature too!!

          Show
          hackl Korbinian Hackl added a comment - Need this feature too!!
          Hide
          hans.petter.bjorn Hans Petter Myrlie-Bjørn added a comment -

          We have similar requirements to distinguish between internal and external users. Both in regards to turn People function on/off for certain groups of users, but also to restrict access to the directory based on group membership. For us this is almost a go / no-go criteria.

          Show
          hans.petter.bjorn Hans Petter Myrlie-Bjørn added a comment - We have similar requirements to distinguish between internal and external users. Both in regards to turn People function on/off for certain groups of users, but also to restrict access to the directory based on group membership. For us this is almost a go / no-go criteria.
          Hide
          a.cauchisavona Aldo Cauchi Savona added a comment -

          Thanks to a comment on CONF-1882 by Mario Gunter, we have updated the VM to show only people based on groups. This is a VM update so it will break with updates. We have a download instance and not OnDemand. What we did is:

          Edit file in <conf-install>\confluence\users\peopledirectory-results.vm

          • Hid the search form from clients:
            #if($userAccessor.hasMembership("_internal_group_", $action.remoteUser.name))
                                            <div class="greyboxfilled" id="people-search-title-bar">
                                                <h2>$title</h2>
                                                #parse ("/users/peopledirectory-searchform.vm")
                                            </div>
                                            #end 
            
          • Only render company profiles for clients and all for internal staff:
            The way we did it is by checking the if the user has group membership and only showing if the user is in group membership.
                                 #* START - Rendering of People Mod *#
                                                    #if($userAccessor.hasMembership("_internal_group_", $action.remoteUser.name))
                                                        #foreach ($person in $searchResults)
                                                            $helper.renderConfluenceMacro("{profile:user=%s|mode=people-directory}", $person)                
                                                        #end
                                                    #else
                                                        #foreach ($person in $searchResults)
            
                                                            #set($confUser = $action.getUserByName($person))
                                                            #if($userAccessor.hasMembership("staff", $confUser.name))                                            
                                                                $helper.renderConfluenceMacro("{profile:user=%s|mode=people-directory}", $person)
                                                            #end                                            
                                                        #end
                                                    #end
                                                    #* END - Rendering of People Mod *#
            

          The code can easily be modified to only show people if you are an internal user and a nice 'not enough rights' message for external users.

          Hope this helps others,
          Aldo

          Show
          a.cauchisavona Aldo Cauchi Savona added a comment - Thanks to a comment on CONF-1882 by Mario Gunter, we have updated the VM to show only people based on groups. This is a VM update so it will break with updates. We have a download instance and not OnDemand. What we did is: Edit file in <conf-install>\confluence\users\peopledirectory-results.vm Hid the search form from clients: # if ($userAccessor.hasMembership( "_internal_group_" , $action.remoteUser.name)) <div class= "greyboxfilled" id= "people-search-title-bar" > <h2>$title</h2> #parse ( "/users/peopledirectory-searchform.vm" ) </div> #end Only render company profiles for clients and all for internal staff: The way we did it is by checking the if the user has group membership and only showing if the user is in group membership. #* START - Rendering of People Mod *# # if ($userAccessor.hasMembership( "_internal_group_" , $action.remoteUser.name)) #foreach ($person in $searchResults) $helper.renderConfluenceMacro( "{profile:user=%s|mode=people-directory}" , $person) #end # else #foreach ($person in $searchResults) #set($confUser = $action.getUserByName($person)) # if ($userAccessor.hasMembership( "staff" , $confUser.name)) $helper.renderConfluenceMacro( "{profile:user=%s|mode=people-directory}" , $person) #end #end #end #* END - Rendering of People Mod *# The code can easily be modified to only show people if you are an internal user and a nice 'not enough rights' message for external users. Hope this helps others, Aldo
          Hide
          aaron65 aaron morton added a comment -

          We assumed that because there is security in Jira to prevent users in one project seeing things in another there would be the same in confluence. While I can stop users seeing another space they can click a link see my entire customer list. This is very disappointing.

          Please allow the people list to be hidden in on deman ASAP so that we can share wiki's with customers.

          Show
          aaron65 aaron morton added a comment - We assumed that because there is security in Jira to prevent users in one project seeing things in another there would be the same in confluence. While I can stop users seeing another space they can click a link see my entire customer list. This is very disappointing. Please allow the people list to be hidden in on deman ASAP so that we can share wiki's with customers.
          Hide
          florian.lenhard florian lenhard added a comment -

          This is a major restriction!! We want to communicate with our Customers in Confluence by giving them user access and not via anonymous access. I do not really understand why this is not implemented yet as the amount of users from our side would jump from <100 to 1000+ at ease. This is revenue generating for Atlassian and therefore not logic to not have already implemented from my point of view!

          Show
          florian.lenhard florian lenhard added a comment - This is a major restriction!! We want to communicate with our Customers in Confluence by giving them user access and not via anonymous access. I do not really understand why this is not implemented yet as the amount of users from our side would jump from <100 to 1000+ at ease. This is revenue generating for Atlassian and therefore not logic to not have already implemented from my point of view!
          Hide
          rcroonenberghs Roel Croonenberghs added a comment -

          florian lenhard: so true

          Show
          rcroonenberghs Roel Croonenberghs added a comment - florian lenhard: so true
          Hide
          ashraf1 Ashraf Eid added a comment -

          I am not sure why is Atlassian has not consider fixing this major issue till now !!!

          Show
          ashraf1 Ashraf Eid added a comment - I am not sure why is Atlassian has not consider fixing this major issue till now !!!
          Hide
          heinz.schuetz Heinz added a comment -

          I Need a solution too (On Demand). It avoids us spreading out Confluence to partners and customers. So we can not use it in the intended way neither.

          Show
          heinz.schuetz Heinz added a comment - I Need a solution too (On Demand). It avoids us spreading out Confluence to partners and customers. So we can not use it in the intended way neither.
          Hide
          bange Udo Bange added a comment -

          I don't understand that either. As soon as this feature is implemented, I can put all our clients onto Confluence, who are quite willing to pay for this. Right now I would have to create a new instance for every client, which is not feasible from a management perspective.

          Show
          bange Udo Bange added a comment - I don't understand that either. As soon as this feature is implemented, I can put all our clients onto Confluence, who are quite willing to pay for this. Right now I would have to create a new instance for every client, which is not feasible from a management perspective.
          Hide
          victor1 Víctor Márquez added a comment -

          I need a solution for this. I can not extend the use of Confluence to partners and customers without this feature.

          Show
          victor1 Víctor Márquez added a comment - I need a solution for this. I can not extend the use of Confluence to partners and customers without this feature.
          Hide
          sean78 Sean Williams added a comment -

          Whoa, as a new Altassian user organisation, it's troubling to run into a 7 year old problem so soon ! Our vote too for (OnDemand) Hide People menu, it's not that useful anyway!.

          Show
          sean78 Sean Williams added a comment - Whoa, as a new Altassian user organisation, it's troubling to run into a 7 year old problem so soon ! Our vote too for (OnDemand) Hide People menu, it's not that useful anyway!.
          Hide
          heinz.schuetz Heinz added a comment -

          BTW: might not be done by just hiding the user-Directory, but needs also display control of "allowed" users, when e.g. selecting them from a displayed/suggested list.
          Worst is, that if JIRA is run jointly on the same server (as on OnDemand) also all JIRA users are actually displayed.

          Show
          heinz.schuetz Heinz added a comment - BTW: might not be done by just hiding the user-Directory, but needs also display control of "allowed" users, when e.g. selecting them from a displayed/suggested list. Worst is, that if JIRA is run jointly on the same server (as on OnDemand) also all JIRA users are actually displayed.
          Hide
          roy.truelove Roy Truelove added a comment -

          We're considering scrapping using Confluence all together because of this issue. It precludes us from using Confluence for any client-facing documentation. Ridiculous. (On-Demand instance).

          Show
          roy.truelove Roy Truelove added a comment - We're considering scrapping using Confluence all together because of this issue. It precludes us from using Confluence for any client-facing documentation. Ridiculous. (On-Demand instance).
          Hide
          hans.petter.bjorn Hans Petter Myrlie-Bjørn added a comment -

          We are hosting Confluence as a service towards our customers in addition to other solutions and services. We had the same issues and were forced to protect the "sensitive" (cross-customer) areas in our reverse proxy so that only internal staff can view the "People"-function. This was achieved by filtering on source IP (i.e. "the internet" vs. "internal IP") and providing a simple HTTP 404 when trying to access secure/sensitive areas.

          Simply hiding the "People" button don't suffice.

          Show
          hans.petter.bjorn Hans Petter Myrlie-Bjørn added a comment - We are hosting Confluence as a service towards our customers in addition to other solutions and services. We had the same issues and were forced to protect the "sensitive" (cross-customer) areas in our reverse proxy so that only internal staff can view the "People"-function. This was achieved by filtering on source IP (i.e. "the internet" vs. "internal IP") and providing a simple HTTP 404 when trying to access secure/sensitive areas. Simply hiding the "People" button don't suffice.
          Hide
          mitrol Mitrol Mitrol added a comment -

          Hi Hans, can you please explain how you achieved this? We are trying to prevent our customers of looking into the people directory and would really appreciate your explanation on how to control this.
          Thank you!

          Show
          mitrol Mitrol Mitrol added a comment - Hi Hans, can you please explain how you achieved this? We are trying to prevent our customers of looking into the people directory and would really appreciate your explanation on how to control this. Thank you!
          Hide
          roy.truelove Roy Truelove added a comment -

          @Hans There are unfortunately other mechanisms for seeing what users are in a system - eg if you do a global search and begin typing you'll see users that match that search. That's no good for us as we don't want one client to see the names of other client users. Were you able to handle those issues as well?

          Show
          roy.truelove Roy Truelove added a comment - @Hans There are unfortunately other mechanisms for seeing what users are in a system - eg if you do a global search and begin typing you'll see users that match that search. That's no good for us as we don't want one client to see the names of other client users. Were you able to handle those issues as well?
          Hide
          carl5 Carl Ludewig added a comment -

          @Roy - I wasn't aware of the search mechanism. Thanks for that note. I really hope Atlassian decides this is important at some point. The group / project security works great - those concepts need to apply users as well, as everyone watching this issue knows!

          Show
          carl5 Carl Ludewig added a comment - @Roy - I wasn't aware of the search mechanism. Thanks for that note. I really hope Atlassian decides this is important at some point. The group / project security works great - those concepts need to apply users as well, as everyone watching this issue knows!
          Hide
          hans.petter.bjorn Hans Petter Myrlie-Bjørn added a comment -

          @Roy. We are using viewports (by Scroll) to display our wiki / confluence spaces so for us the search function was not an important topic, but hearing your argumentation we are more or less in the same boat. However, we can live with the issue you are describing. That being said, I am assuming this feature is probably some kind of AJAX call and could potentially be solved using the same methods as we solved the other main problem.

          @Mitrol The solution for "shutting" down the People/Group section was to identify those URLs / applications and basically denying access to these through our reverse proxy. This requires that you actually have a reverse proxy (e.g. Apache) in front of Confluence and that you can distinguish internal (corporate) and external (customer) traffic. If you need any details I will have to get back to you on those. But it is more or less pretty standard Reverse Proxy configuration (nothing magic).

          We see the config / solution as a reduction of damage rather than a 100% and final solution.

          Show
          hans.petter.bjorn Hans Petter Myrlie-Bjørn added a comment - @Roy. We are using viewports (by Scroll) to display our wiki / confluence spaces so for us the search function was not an important topic, but hearing your argumentation we are more or less in the same boat. However, we can live with the issue you are describing. That being said, I am assuming this feature is probably some kind of AJAX call and could potentially be solved using the same methods as we solved the other main problem. @Mitrol The solution for "shutting" down the People/Group section was to identify those URLs / applications and basically denying access to these through our reverse proxy. This requires that you actually have a reverse proxy (e.g. Apache) in front of Confluence and that you can distinguish internal (corporate) and external (customer) traffic. If you need any details I will have to get back to you on those. But it is more or less pretty standard Reverse Proxy configuration (nothing magic). We see the config / solution as a reduction of damage rather than a 100% and final solution.
          Hide
          tran.le Tran Le added a comment -

          Atlassian, I shouldn't be surprised really to see that a core request to resolve a huge security and functionality requirement is still outstanding in 2015. It's now over 8 years since this issue was raised and the last formal update from Atlassian was 3 years ago. It's extremely perplexing why this isn't at the top of your development roadmap when so many people have asked for it, accompanied by very valid reasons and concerns.

          I'm currently testing Confluence and linked it to my standalone JIRA's user directories. So imagine my surprise, and the surprise of others in my team, that every single JIRA user and his dog (we use it to provide internal and external support) can now be displayed in Confluence, without any ability to lock down what can be seen and not seen. Atlassian, between this issue and the JIRA Issue Collector request, I really don't get it. You're all a bunch of really switched on and smart people (and generous with your open-source licenses) so it really disappoints and puzzles me when you drop the ball like this.

          Show
          tran.le Tran Le added a comment - Atlassian, I shouldn't be surprised really to see that a core request to resolve a huge security and functionality requirement is still outstanding in 2015. It's now over 8 years since this issue was raised and the last formal update from Atlassian was 3 years ago. It's extremely perplexing why this isn't at the top of your development roadmap when so many people have asked for it, accompanied by very valid reasons and concerns. I'm currently testing Confluence and linked it to my standalone JIRA's user directories. So imagine my surprise, and the surprise of others in my team, that every single JIRA user and his dog (we use it to provide internal and external support) can now be displayed in Confluence, without any ability to lock down what can be seen and not seen. Atlassian, between this issue and the JIRA Issue Collector request, I really don't get it. You're all a bunch of really switched on and smart people (and generous with your open-source licenses) so it really disappoints and puzzles me when you drop the ball like this.
          Hide
          kaspar Kaspar Lüthi added a comment -

          We are also very unhappy about this.We use Confluence for documentation about factory machinery, the customers are actually competitors, so we do not want them to know about each other. It's really a simple requirement, I also imagine it's not that difficult to implement as the permission system is already in place. It's a reasonable expectation, that the permission system also allows for privacy and non-disclosure of information. Not having it is a bug, not a missing feature! So, why are we still waiting?

          Show
          kaspar Kaspar Lüthi added a comment - We are also very unhappy about this.We use Confluence for documentation about factory machinery, the customers are actually competitors, so we do not want them to know about each other. It's really a simple requirement, I also imagine it's not that difficult to implement as the permission system is already in place. It's a reasonable expectation, that the permission system also allows for privacy and non-disclosure of information. Not having it is a bug, not a missing feature! So, why are we still waiting?
          Hide
          hans-peter.geier Hans-Peter Geier added a comment -

          So, why are we still waiting?

          the answer is easy. Atlassian's project management and development priorities are fun-driven, not customer-driven.
          Atlassian developpers are getting enough time to live their fun projects; that's a great motivation for them.
          It makes simply more fun to develop new features than to fix bugs.
          So, forget about bug fix requests on old bugs, we will never get them resolved by this company.

          Show
          hans-peter.geier Hans-Peter Geier added a comment - So, why are we still waiting? the answer is easy. Atlassian's project management and development priorities are fun-driven, not customer-driven. Atlassian developpers are getting enough time to live their fun projects; that's a great motivation for them. It makes simply more fun to develop new features than to fix bugs. So, forget about bug fix requests on old bugs, we will never get them resolved by this company.
          Hide
          heinz.schuetz Heinz added a comment -

          Dear Hans-Peter

          I am a bit angry and upset too about this subject.
          May be you are right - hopefully not. I am allways ready to get supprised by my peers. Never say never and the hope dies last!

          Show
          heinz.schuetz Heinz added a comment - Dear Hans-Peter I am a bit angry and upset too about this subject. May be you are right - hopefully not. I am allways ready to get supprised by my peers. Never say never and the hope dies last!
          Hide
          ebishop2890 Elizabeth added a comment -

          Private Parts for Atlassian Confluence solves this:
          https://www.appfusions.com/display/PPARTS/Home

          (and welcome feedback if you feel it does not, after trying it).

          Show
          ebishop2890 Elizabeth added a comment - Private Parts for Atlassian Confluence solves this: https://www.appfusions.com/display/PPARTS/Home (and welcome feedback if you feel it does not, after trying it).
          Hide
          don13 Don Son added a comment - - edited

          The fact that this feature has been pending for over 8 years is very concerning. I contacted support regarding this issue and they recommended that I post my feedback here. I don't know if there is anything else to say, it seems like a simple feature with enough user support. Is the lack of supporting this feature some type of strategic move to push people to purchasing hosted licenses? I don't understand.

          I've been a big Atlassian proponent and have championed adoption of the entire suite. I'm now being forced to look for alternatives and try explain to my coworkers why Atlassian won't fix such a simple issue.

          Show
          don13 Don Son added a comment - - edited The fact that this feature has been pending for over 8 years is very concerning. I contacted support regarding this issue and they recommended that I post my feedback here. I don't know if there is anything else to say, it seems like a simple feature with enough user support. Is the lack of supporting this feature some type of strategic move to push people to purchasing hosted licenses? I don't understand. I've been a big Atlassian proponent and have championed adoption of the entire suite. I'm now being forced to look for alternatives and try explain to my coworkers why Atlassian won't fix such a simple issue.
          Hide
          rob.kearey Rob Kearey added a comment -

          Yep. This needs fixing now.

          Atlassian: Take a few months off chasing features, and knuckle down on getting some of the basics right, out of the box.

          Show
          rob.kearey Rob Kearey added a comment - Yep. This needs fixing now. Atlassian: Take a few months off chasing features, and knuckle down on getting some of the basics right, out of the box.
          Hide
          heinz.schuetz Heinz added a comment -

          Triggerd by the Remark of Don, I checked the Link which Elizabeth provided.

          This plugin would (in Version 2) perfectly well fullfill my expectations and needs regarding privacy.
          Drawback:

          • I have to pay to get fixed a serious feature lack (not to say a bug)
          • I can't use ist on "On Demand" (Elizabeth please confirm)
          • There may be unpredictable dependencies during upgrades between atlassian and third-party SW in a securtity sensible domain

          Thogh it would be perfectly possible to fix this within the product, if thirdparties are able to provide the fix.

          Show
          heinz.schuetz Heinz added a comment - Triggerd by the Remark of Don, I checked the Link which Elizabeth provided. This plugin would (in Version 2) perfectly well fullfill my expectations and needs regarding privacy. Drawback: I have to pay to get fixed a serious feature lack (not to say a bug) I can't use ist on "On Demand" (Elizabeth please confirm) There may be unpredictable dependencies during upgrades between atlassian and third-party SW in a securtity sensible domain Thogh it would be perfectly possible to fix this within the product, if thirdparties are able to provide the fix.
          Hide
          don13 Don Son added a comment - - edited

          Dog Fooding
          I noticed that this issue was recently linked to an extranet called “Pug - Confluence Dogfood” by an internal Atlasssian employee. The link was dead, however I have to assume that this pertains to the concept of “Dog Fooding” which refers to eating your own dogfood (aka: using your own products). Here is nice little blog post from Atlasssian explaining dog fooding and how cool they are for using it. http://blogs.atlassian.com/2009/07/agile_development_dogfooding_and_frequent_internal_releases/

          I’d like to point out that the official documentation for confluence which is seemingly hosted on a confluence instance does not have a “People” tab https://confluence.atlassian.com/display/CONF52/Getting+Started+as+Confluence+Administrator Come on Atlasssian, eat your Dog Food! Let’s see all of the internal developers and Atlasssian users with their contact information! Or at very least reply to your users and address this issue.

          Voice Your opinion to the CEO's
          Anyone who has issue with this feature request, please drop a message to the CEO's (Scott and Mike) https://www.atlassian.com/company/contact/contact-ceos

          Show
          don13 Don Son added a comment - - edited Dog Fooding I noticed that this issue was recently linked to an extranet called “Pug - Confluence Dogfood” by an internal Atlasssian employee. The link was dead, however I have to assume that this pertains to the concept of “Dog Fooding” which refers to eating your own dogfood (aka: using your own products). Here is nice little blog post from Atlasssian explaining dog fooding and how cool they are for using it. http://blogs.atlassian.com/2009/07/agile_development_dogfooding_and_frequent_internal_releases/ I’d like to point out that the official documentation for confluence which is seemingly hosted on a confluence instance does not have a “People” tab https://confluence.atlassian.com/display/CONF52/Getting+Started+as+Confluence+Administrator Come on Atlasssian, eat your Dog Food! Let’s see all of the internal developers and Atlasssian users with their contact information! Or at very least reply to your users and address this issue. Voice Your opinion to the CEO's Anyone who has issue with this feature request, please drop a message to the CEO's (Scott and Mike) https://www.atlassian.com/company/contact/contact-ceos
          Hide
          sg2 Sylvain Gourvil added a comment -

          Do you have any ideas of a possible date for this feature in Cloud ?
          We were so pleased of using Confluence but this killer non-feature did us changed our mind for another SaaS solution.

          Show
          sg2 Sylvain Gourvil added a comment - Do you have any ideas of a possible date for this feature in Cloud ? We were so pleased of using Confluence but this killer non-feature did us changed our mind for another SaaS solution.
          Hide
          martin.kottisse Martin Kottisse added a comment -

          It has been lingering for 8 years, it can wait - being sarcastic. Anyway this is the reason why we haven't been using confluence actively in cloud so far (even I've been paying for this all the time). Seems so small fix, but for Atlassian it's not a priority of any kind.

          Show
          martin.kottisse Martin Kottisse added a comment - It has been lingering for 8 years, it can wait - being sarcastic. Anyway this is the reason why we haven't been using confluence actively in cloud so far (even I've been paying for this all the time). Seems so small fix, but for Atlassian it's not a priority of any kind.
          Hide
          tran.le Tran Le added a comment -

          I get a little excited every time this issue gets updated only to see that it's only us providing the updates

          Show
          tran.le Tran Le added a comment - I get a little excited every time this issue gets updated only to see that it's only us providing the updates
          Hide
          roy.truelove Roy Truelove added a comment -

          We're migrating to an instance of Dokuwiki hosted on AWS. Bye Confluence.

          Show
          roy.truelove Roy Truelove added a comment - We're migrating to an instance of Dokuwiki hosted on AWS. Bye Confluence.
          Hide
          gerhard.alfanz Gerhard Alfanz added a comment -

          We just ran into the same problem. Allowing access for external partners isn't an option unless this is implemented. Relying on (3rd party) plugins for security related issues isn't the best idea too we think.
          If this won't be addressed in the near future we'll also have to look for alternatives, unfortunately

          Show
          gerhard.alfanz Gerhard Alfanz added a comment - We just ran into the same problem. Allowing access for external partners isn't an option unless this is implemented. Relying on (3rd party) plugins for security related issues isn't the best idea too we think. If this won't be addressed in the near future we'll also have to look for alternatives, unfortunately
          Hide
          martin.kottisse Martin Kottisse added a comment -

          Come on Atlassian, I don't want you to redevelop whole logic and dependencies.. just.. just for starters add a small checkbox in settings which would trigger temporary css/js to hide the block from DOM. I'm really trying to push your products in company because I like them, but CEO will freak out when he will find out that all the developers are visible to partners and competitors.

          <a id="people-directory-link" href="/wiki/peopledirectory.action" class=" aui-nav-imagelink" title="People">
                      <span>People</span>
              </a>
          
          Show
          martin.kottisse Martin Kottisse added a comment - Come on Atlassian, I don't want you to redevelop whole logic and dependencies.. just.. just for starters add a small checkbox in settings which would trigger temporary css/js to hide the block from DOM. I'm really trying to push your products in company because I like them, but CEO will freak out when he will find out that all the developers are visible to partners and competitors. <a id= "people-directory-link" href= "/wiki/peopledirectory.action" class= " aui-nav-imagelink" title= "People" > <span> People </span> </a>
          Hide
          roy.truelove Roy Truelove added a comment -

          I feel like we're talking to a wall. Atlassian, your customers are grumpy! Can you respond? Acknowledge?

          Show
          roy.truelove Roy Truelove added a comment - I feel like we're talking to a wall. Atlassian, your customers are grumpy! Can you respond? Acknowledge?
          Hide
          bastian.baumeister Bastian Bastian added a comment -

          @arconati@atlassian.com: I can only undeline what has been said before - this is an absolutely inacceptable way of dealing with customer requests.
          We are happy users of a self-hosted Jira instance with unlimited users. We currently testrun Confluence in a 100 users setup.
          This privacy issue is going to be a dealbreaker which will drive us away from putting Confluence into productive usage.

          Show
          bastian.baumeister Bastian Bastian added a comment - @arconati@atlassian.com: I can only undeline what has been said before - this is an absolutely inacceptable way of dealing with customer requests. We are happy users of a self-hosted Jira instance with unlimited users. We currently testrun Confluence in a 100 users setup. This privacy issue is going to be a dealbreaker which will drive us away from putting Confluence into productive usage.