Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-46420

User email visibility set by groups/space

XMLWordPrintable

    • Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • User - Profile
    • 1
    • 1
    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.

      Problem Definition

      Currently, the 'user email visibility' security setting is global to all wiki spaces on a Confluence platform.
      Some of our wikis administrators are requesting for enabling 'visibility' and other ones request for disabling.

      Suggested Solution

      Create a new Visibility for emails, for example, set this to work with space/groups of users.
      Instead of having a global setting, would it be possible to set this parameter:

      • either per space
      • either per groups of users

      Why this is important

      So we can set the email visibility accordingly to each user needs

            [CONFSERVER-46420] User email visibility set by groups/space

            Jasper Knops added a comment - - edited

            I experienced the exact same thing as @alexboss. One space administrator wants to hide, another one wants to show the e-mail addresses.

            Before you can implement this kind of functionality, you have to think about inheretance and overwriting. Can a user or space administrator overrule the global setting when it is set to "only visible to site administrators"? In my case, this would be the best solution:

            • A global setting which defines the lowest level of security.
              1. Hide – Nobody can overrule this setting
              2. Mask – This option can be overwritten by "Hide" on a user/space level
              3. Public – This option can be overwritten by "Hide" or "Mask" on a user/space level
            • A user setting which can define a higher level of security then the global setting.
              • Eg. A user can hide or mask his e-mail when the global setting is set to "public"
              • Possible options:
                • Global setting: Hide
                  • User setting: Hide
                • Global setting: Mask
                  • User setting: Hide/Mask
                • Global setting: Public
                  • User setting: Hide/Mask/Public
            • A space setting which can define a higher level of security than the global and user setting
            • Eg.
              • Global setting: "Public"
              • User setting: "Mask"
              • Space setting: "Hide"
              • All e-mail addresses in that space will be hidden.
            • Eg.
            • Global setting: "Mask"
            • User setting: "Hide"
            • Space setting: "Public"
            • The e-mail address of this user in that space will be hidden.

            Maybe in other cases they want to allow users to overwrite the global settings, and spaces to overwrite the global and/or user setting. This could be solved by providing an extra global setting which defines if overwriting is allowed.

             

            Thanks,

            Jasper

            Jasper Knops added a comment - - edited I experienced the exact same thing as @alexboss. One space administrator wants to hide, another one wants to show the e-mail addresses. Before you can implement this kind of functionality, you have to think about inheretance and overwriting. Can a user or space administrator overrule the global setting when it is set to "only visible to site administrators"? In my case, this would be the best solution: A global setting which defines the lowest level of security. Hide – Nobody can overrule this setting Mask – This option can be overwritten by "Hide" on a user/space level Public – This option can be overwritten by "Hide" or "Mask" on a user/space level A user setting which can define a higher level of security then the global setting. Eg. A user can hide or mask his e-mail when the global setting is set to "public" Possible options: Global setting: Hide User setting: Hide Global setting: Mask User setting: Hide/Mask Global setting: Public User setting: Hide/Mask/Public A space setting which can define a higher level of security than the global and user setting Eg. Global setting: "Public" User setting: "Mask" Space setting: "Hide" All e-mail addresses in that space will be hidden. Eg. Global setting: "Mask" User setting: "Hide" Space setting: "Public" The e-mail address of this user in that space will be hidden. Maybe in other cases they want to allow users to overwrite the global settings, and spaces to overwrite the global and/or user setting. This could be solved by providing an extra global setting which defines if overwriting is allowed.   Thanks, Jasper

            Alexandre Bosserelle added a comment -

            Indeed, that's a very interesting feature. A lot of wiki space administrators complain about the fact it's visible so we turn the visibility off, but then a lot of other wiki space administrators complain about the fact it's visible, so we have to turn it back on.

             

            It could be great if:

            • e-mail visibility could also be defined at space level
            • users could decide themselves whether or not they want to be visible in the global directory and / or make their e-mail address visible

             

            Best regards,

             

            Alexandre 8)

            Alexandre Bosserelle added a comment - Indeed, that's a very interesting feature. A lot of wiki space administrators complain about the fact it's visible so we turn the visibility off, but then a lot of other wiki space administrators complain about the fact it's visible, so we have to turn it back on.   It could be great if: e-mail visibility could also be defined at space level users could decide themselves whether or not they want to be visible in the global directory and / or make their e-mail address visible   Best regards,   Alexandre 8)

              Unassigned Unassigned
              vabreu Vinicius Abreu (Inactive)
              Votes:
              10 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated: