Redmine

This almost sounds like it should be the other way around:

The permission should probably be on the user to add non-member watchers. If I'm a project manager I can't be limited for something that in essence is to keep non-members from adding each other.

Of course does this mean that non-members can view profiles of other non-members? If so this permission would be pretty useless, I can just cruise the member list if this barrier is put in place (which means this issue has really existed for a long time).

I'd almost suggest the ability to limit users from seeing non-members in general, and let that permission cascade to this search box.

whaaaaaaaaat????

that s really not good. i just set up a redmine for 2 customers and you are absolutely right, they can see each other if they add watchers.

Same for the redmine/users/XX links.
Everyone can scan all users at any time. A role/permission to change that would be very important.

You should check out http://www.redmine.org/boards/1/topics/4143
They post a solution to manually change some files to change what certain members can see.

I still think this should remain a feature for a future version so we don't have to do this in the code directly.

+1 on this feature-request!

We're having the same problem as Maxim.
But I think that a role-permission is the wrong way to do this!

This should be a project specific option!

Maxim Kim wrote:

This feature #5159 caused a major problems at least for us.
We let our customers to add new issues and watchers. And now our customers can see other customer names, which is inacceptable!
[...]

This is true defect IMO. As a workaround you can revoke the "Add watchers" permission from your customer roles.

William Roush wrote:

Of course does this mean that non-members can view profiles of other non-members? If so this permission would be pretty useless, I can just cruise the member list if this barrier is put in place (which means this issue has really existed for a long time).

I'd almost suggest the ability to limit users from seeing non-members in general, and let that permission cascade to this search box.

Hannes Meier wrote:

[...]

Same for the redmine/users/XX links.
Everyone can scan all users at any time. [...]

It is simply not true that all users can browse account/user pages unlimited. This is reserved to administrators only. Non-admin users can't browse user pages of users who are not active ánd who have no visible project or activity. See #14601#note-1 (note-1) and more historically r2986 (for #4129 & #3720).

Jean-Philippe Lang wrote:

[...] I'd like to add a setting on each role that defines which users the role is allowed to see: all users or members of visible projects [...]

I think that would be a good solution for this issue.

That is great news but we had to go with different software already because of that.
But good to know, if this is fixed in future we may consider a comeback.

Maxim Kim wrote:

Added by Maxim Kim about 1 year ago.

Jean-Philippe Lang wrote:

Rather than adding a specific permission for adding non members as watchers, I'd like to add a setting on each role that defines which users the role is allowed to see: all users or members of visible projects. That would apply to adding watchers and viewing users as well (/users/:id). And I think it would be easier for those who want to control user visibility (rather than reviewing all permissions to know which users the role can see).

I think this should not solve the critical case where reporters of a private project are external customers that should not know who are the other customers, would it?

And when an user is not tied to a project anymore, you can't have any visibility policy applicable, right ?

Why not simply have a "public"/"private" user setting(which could be extended to group) and have a "See private users" setting at role level?

Edit: actually, it was described by Joshua in #13533.

First of all, I would like to thank to Felix Schäfer, who provided a patch for Defect #15123 "Add watcher" leaks all active users issue.
Today we've found one more serious problem with user & groups visibility. (We are using Redmine v2.3.3 at the moment.)
User can see the names of all groups on Redmine, by selecting issue filter by "Assignee's group"!
This happens even if issue assignment to groups isn't allowed.
I've expected to see only the names of those groups which are assigned to that project in the filter list.
And guess what, almost all group names (in my case) are constructed from two parts: project role and project name. Very original idea, isn't it?
In this case, customer can easily guess names of all projects, which is not acceptible at all.
It seems that current Redmine user/group permission model can't provide reliable customer/project isolation.
"Workaround" could be to give meaningless names to groups, and even better, give meaningless names to projects also?

Debug log shows following SQL query for groups:

SELECT "users".* FROM "users" INNER JOIN "groups_users" ON "users"."id" = "groups_users"."group_id" WHERE "users"."type" IN ('Group') AND "groups_users"."user_id" = 1

SELECT "members"."id" AS t0_r0, "members"."user_id" AS t0_r1, "members"."project_id" AS t0_r2 ... FROM "members" LEFT OUTER JOIN "users" ON "users"."id" = "members"."user_id" WHERE "members"."project_id" = 1 AND (users.type='Group')

This issue is also affecting us. Our customers have access to Redmine for their respective projects, but we don't really want them to access the global user list.
Until we have a solution, we removed the "Add Watchers" role, but it would better if that role was open to our customers.

I'm also going to open a separate ticket for the issue described by Djordjije 3 comments earlier as I can't find a related issue.

Anyway, thank you to all Redmine contributors. This is a great piece of software, and we enjoy using it daily.

<wrong manipulation :->

Thanks Rafał for this new fix, it works like a charm on 2.5.1 !

Just a little issue with Rafał patch : if you add watchers to an existing issue, it doesn't refresh the list automatically, you have to refresh the page entirely to update the watcher list. Unfortunately, I'm not a ruby developer and can't figure out why.

I think this feature should be considered as defect, as it is a security issue.

Great to see this is being included in a release.

Just a question: the two cases given by Etienne in #11724#note-11 are not covered by this yet, right?
I can see that his first point is considered out-of-scope of this issue but I think that the second one is in-scope ánd could potentially create unexpected results (I haven't been able to test these changes myself actually, so I can't say for sure...).
Edit by Mischa The Evil: this case (when a user is not tied to a project [anymore], you can't have any visibility policy applicable) is already covered by r13584 implementation (by making the users visibility role option available to/applicable on the build-in anonymous and non-member roles too, see source:/trunk/app/models/principal.rb@13584#L51).