https://www.redmine.org/https://www.redmine.org/favicon.ico?16793021292013-03-20T08:14:23ZRedmineRedmine - Feature #13533: Concept for controlling visibility of usershttps://www.redmine.org/issues/13533?journal_id=471292013-03-20T08:14:23ZAnonymous
<ul></ul><p>Detail I failed to mention:</p>
<p>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.</p>
<p>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:</p>
<p>(1) Is private user? No -> Show profile; Yes -> (2)<br />(2) Is user visible to me in any of my projects? Yes -> Show profile; No -> Access denied</p> Redmine - Feature #13533: Concept for controlling visibility of usershttps://www.redmine.org/issues/13533?journal_id=471622013-03-20T15:55:36ZJan Niggemann (redmine.org team member)jan.niggemann@redmine.org
<ul></ul><p>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...</p> Redmine - Feature #13533: Concept for controlling visibility of usershttps://www.redmine.org/issues/13533?journal_id=471962013-03-20T19:12:24ZAnonymous
<ul></ul><p>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.</p>
<p>Consider the following commonly used project structure:</p>
<p>[Master Project]<br /> -> [Partner A subproject]<br /> -> [Partner B subproject]<br /> -> [Partner C subproject]</p>
<p>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).</p>
<p>There are a variety of difficult situations where controlling access to content is important and terrifyingly complex project trees are created to achieve it. <em>Way too many</em> 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.</p> Redmine - Feature #13533: Concept for controlling visibility of usershttps://www.redmine.org/issues/13533?journal_id=489072013-04-24T15:41:18ZArtur M
<ul></ul><p>Jan Niggemann wrote:</p>
<blockquote>
<p>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...</p>
</blockquote>
<p>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.</p> Redmine - Feature #13533: Concept for controlling visibility of usershttps://www.redmine.org/issues/13533?journal_id=518092013-09-16T20:37:51ZMike Gagnon
<ul></ul><p>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!</p> Redmine - Feature #13533: Concept for controlling visibility of usershttps://www.redmine.org/issues/13533?journal_id=529812013-11-06T10:13:08ZHannes Just
<ul></ul><p>We would like to sponsor this feature. Who should I contact to negotiate?</p> Redmine - Feature #13533: Concept for controlling visibility of usershttps://www.redmine.org/issues/13533?journal_id=617282015-02-26T11:46:05ZWim DePreter
<ul></ul><p>See <a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: Private roles (New)" href="https://www.redmine.org/issues/17747">#17747</a>, I think "private" should be on the role, not on the user.<br />So a user can be private (= has a private role) in project A, but public (f.e. as manager) in project B</p> Redmine - Feature #13533: Concept for controlling visibility of usershttps://www.redmine.org/issues/13533?journal_id=625912015-03-27T11:46:04ZToshi MARUYAMA
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-4 priority-default" href="/issues/17747">Feature #17747</a>: Private roles</i> added</li></ul>