Feature #13533

Concept for controlling visibility of users

Added by Joshua DeClercq over 6 years ago. Updated over 4 years ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Resolution:

Description

This was sparked by Mischa the Evil's comment on my ticket, #13527, so it also somewhat relates to ticket #11724.

This is a proposal for adding control over the visibility of project members. I've tried my best to keep it flexible and useful in a variety of scenarios. I find that familiarity helps users adopt and stick with new functionality, so this is borrowing heavily from Redmine's existing privacy model. Essentially, hidden or private users.

To the user model, add a privacy bool, represented by a check box on the user form. Unchecked, you have a public user. Checked, private.

To the roles model, add a new set of permissions. These are very similar to issue visibility permissions, so it might be best to use a drop-down list for this:

  1. See all users
  2. See public and related users*
  3. See only public users

A ton of visibility use cases can be addressed with this combination of per-user and per-role settings. Unfortunately, I wasn't able to completely avoid the dreaded specifics.

(*) Related users is, of course, not currently a defined concept. The most obvious definition to apply here is user groups--your member list would be populated with public users and any users that share group memberships with you if this option is selected.

Aside
It's worth pointing something out. If this user 'relationship' concept is implemented as I've described it, it could also extend to the issue visibility model, allowing users to see issues posted by 'related' users. It wouldn't fully address existing requests for a way to 'involve' users on issues (#8488), but it would be a pretty painless additional choice.


Related issues

Related to Redmine - Feature #13527: 'Display name' for users New
Related to Redmine - Feature #11724: Prevent users from seeing other users based on their proj... Closed
Related to Redmine - Feature #8488: Create an 'Involve' mechanism to private issues New
Related to Redmine - Feature #17747: Private roles New

History

#1 Updated by Joshua DeClercq over 6 years ago

Detail I failed to mention:

It's possible there will be visible (non-private) issues authored by or assigned to users some users aren't allowed to see. In this case, where these private user names are written in the issue details, substitute text would show instead. Something like 'Private user' or 'Private account'. No hyperlink to a profile page.

It's also possible that two private users might have roles in a project that keep them hidden from each other, and roles in another project that expose them to each other. Because of this possible scenario, I opted for the previous paragraph's removal of the profile link instead of restricting access to the profile page entirely (access denied). This means it'd still be possible to see anyone's profile just by incrementing the user ID in the profile URL. If it's possible, it might be worth using some kind of profile access rights check after all, along the lines of:

(1) Is private user? No -> Show profile; Yes -> (2)
(2) Is user visible to me in any of my projects? Yes -> Show profile; No -> Access denied

#2 Updated by Jan Niggemann (redmine.org team member) over 6 years ago

Why would hiding members be useful? Project management is a lot about people working together, I'd bet most of the time it's valuable that the project team knows each other...

#3 Updated by Joshua DeClercq over 6 years ago

There's usually no need to hide users from each other. However, the need does arise, and granular control over almost every aspect of a project is asked for at some point by someone.

Consider the following commonly used project structure:

[Master Project]
-> [Partner A subproject]
-> [Partner B subproject]
-> [Partner C subproject]

Currently, this is the easiest--and perhaps only realistic--way to manage external user access to information in Redmine. This provides the internal users a 'global' view from the parent master, but still requires navigating project-to-project for content creation. It also imposes the duplication (EVIL) of any globally shared content (docs, files, wikis, etc).

There are a variety of difficult situations where controlling access to content is important and terrifyingly complex project trees are created to achieve it. Way too many users think of projects as 'folders' and create these trees as if organizing their MP3 collection, not realizing they're creating entire project spaces and everything that goes with them. If anything can be done to reduce this practice without adding unnecessary complexity to existing models, I'm all for it.

#4 Updated by Artur M over 6 years ago

Jan Niggemann wrote:

Why would hiding members be useful? Project management is a lot about people working together, I'd bet most of the time it's valuable that the project team knows each other...

If you want Redmine to become the best web based Project Management platform available, you've to stop thinking that only standard software development teams are using it. I could cite a bunch of professional environments where project members anonymity must be kept, not only about their names but also about their e-mail addresses and activity in the project. This is a key feature, believe me.

#5 Updated by Mike Gagnon about 6 years ago

We desperately want this feature so that we may add customers to projects made specifically for customers. It gives us a way to distribute setup files and forum comments, while upholding the privacy of our customers, which is of utmost importance to us. Please give us this feature, it would be so useful and appreciated!

#6 Updated by Hannes Just almost 6 years ago

We would like to sponsor this feature. Who should I contact to negotiate?

#7 Updated by Wim DePreter over 4 years ago

See #17747, I think "private" should be on the role, not on the user.
So a user can be private (= has a private role) in project A, but public (f.e. as manager) in project B

#8 Updated by Toshi MARUYAMA over 4 years ago

Also available in: Atom PDF