-
Suggestion
-
Resolution: Low Engagement
-
None
-
1
-
1
-
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
- is related to
-
- Gathering Interest
- relates to
-
- Closed
[CONFSERVER-46420] User email visibility set by groups/space
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
- Global setting: Hide
- 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 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)
Hello,
Thank you for submitting this suggestion. We appreciate you taking the time to share your ideas for improving our products, as many features and functions come from valued customers such as yourself.
Atlassian is committed to enhancing the security and compliance of our Data Center products, with an emphasis on sustainable scalability and improving the product experience for both administrators and end-users. We periodically review older suggestions to ensure we're focusing on the most relevant feedback. This suggestion is being closed due to a lack of engagement in the last four years, including no new watchers, votes, or comments. This inactivity suggests a low impact. Therefore, this suggestion is not in consideration for our future roadmap.
Please note the comments on this thread are not being monitored.
You can read more about our approach to highly voted suggestions here and how we prioritize what to implement here.
To learn more about our recent investments in Confluence Data Center, please check our public roadmap and our dashboards, which contain recently resolved issues, current work, and future plans.
Kind regards,
Confluence Data Center