good.
Could you detail the issue?
- Is the issue about knowing user names (and if so, why is it a privacy issue in your case? I believe that in some cases it’s ok, for ex when I go to my physical running group, I have access to anyone’s name. Maybe you have an open wiki, which IMO would make it an issue if the users are not aware that their data is public (if they are aware then it’s no longer an issue since they’d put only what they want others to see). For ex, this is what users do on xwiki.org, only put what they want others to see.
- Or is the issue about the various information shown in the user profile? If this is the issue then it’s easy to fix by changing a single wiki page (the user sheet). However, this won’t fix all problem since you could access this information using the REST API for ex or using scripting.
Some questions: what should be private and to whom? If it should be private for everyone except the user then there’s no interest in filling that data at all, is there? Should it be visible to admins or to some people from some groups?
I’m asking this to try to define the use cases so that you/we could create jira issues about it.
If I read between the lines, I feel we should introduce a privacy xproperty metadata for any field with different values such as: private (only the xobject document creator can see it), public (everyone can see it), only visible to some groups, etc. Then, when we display these xproperty values, we would do the same as we do for email fields (Actually we could retrofit this concept to the email field too and when adding an email xproperty type, set that metadata to “private” for ex or to the AdminGroup).
So we need to gather all the use cases and needs.
You could modify the page’s content to not list the users.
You could remove that group and set it to be implicit, see Loading... which points to documentation about how to do that.
You could edit http://localhost:8080/xwiki/bin/view/XWiki/XWikiGroupSheet and add an IF condition to only display the list if the user is part of the AdminGroup for ex:
Note that if you do this you solve all the group display issues at once.
Could be something to consider doing by default in XS, especially since these pages are admin pages and we have the user directory for a user page listing all users. Feel free to create a jira for this too.