When a Bugzilla is used as a tracking mechanism between multiple customers and an internal development team, divulging every email address along with the details of every bug is not prudent. It should be possible to limit access to the identity of the involved parties for a bug even when the bug itself is visible. It should be possible for someone to comment on a bug or even assign it to one of their own users while not making it possible for them to assign the bug to a user from another company.

Basic insider model and drop-down user-lists should be in place before this change

*** This bug has been marked as a duplicate of 120030 ***

ok, Joel emailed me privately about this, and explained a few things, and I'm going to change my mind on this being a dupe. This is a little broader scope than the bug I duped it of, and this is sort of two different angles at securing this information.

Exactly how to handle this will become a bit more clear after bug 157756 is done and people start applying the new flexibility. The closest thing to a good idea that I have is to add a regexp to each groups indicating that membership in this group permits the member to see any users whose login matches the regexp. I'd really like to find a better approach than that.

Since the new group system allows you to create groups that basically serve no purpose other than marking roles... perhaps you could make a list of groups that other users must belong to for you to be able to see their address. This would be a bit more flexible. (Then you can attain your regexp plan as well, by creating a role group with a new user regexp that matches the domain you want to limit, then listing that group)

I should probably care, since this is email related.

WRT comment 5: One option would be to have pairs of groups defined so that a pair.... (groupA, groupB) would make it either necessary or possible (which?) to be a member of groupA in order to see the address of anyone in groupB. It does seem like a shame to define another entire table for this, though. It could be done by adding records in the group_group_map that, instead of just conveying membership or bless capability, convey the right to see the people in the group. The downside of doing this is that we would have to make sure that the group memberships of both users are derived before making the decision. The regexp-based approach requires onlt the logged-in user to have his groups looked up. An alternative is to associate each user with a single group of which users must be a member in order to see that user. Then, the logged-in user's list of group-ids can be checked against the other user's profile (which has to be looked up anyway) to determine if that profiles information can be visible.

Is there a case where: User1 in GroupA should see users in GroupB but not users in GroupC AND User1 should not belong or does not make sense to belong to GroupB? Reason I ask is that we could add two fields to group_group_map: "See Members in All Groups" and "Others Can See Members". This would allow certain groups to see all members of all groups. This allow certain groups to always show themselves. If you are a member of a group, you will see members in that group. I think the only case that doesn't cover is the case I listed first.

WRT Comment 8: I have been wrestling with that part of the model. The problem is that figuring out which users are a member of a group can take a second or so per user for any user who has not logged in since the last group edit. For the logged-in user, this is always already done at login time. For users mentioned in CC lists, we already do this while processing a bug. So, when doing a drop-down or email wildcard, we don't want to have to figure out all the group memberships for the entire user community. One possibility is to have certain groups identified as "mailgroups" and not permit inheritance of the group memberships. (Though maybe regexps??) Those "mailgroups" could be the ones that determine mail visibility. So, if I am a member of a mailgroup, you can only see my email address if you are a member of a group with a group_group_map relationship that indicates that you can see my mailgroup. Ugly from an administration standpoint, though.

OK... Here's the plan.... 1) Some groups will have an "isvisibility" flag set indicating that a user must be a member of a group that can "see" this group in order to "see" any members opf this group. 2) A new record type in group_group_map will indicate which groups can see other groups. Groups that have the "isvisibility" flag set will have a 3rd column of checkboxes (next to the "group members are members of this group" and "group members can bless this group" columns) indicating that "group members can see members of this group". 3) A common function UserCanSeeUser( viewer, target) will determine if any user can see another users. [ undef'd viewer or target will mean the currently logged-in user ] UserCanSeeUser will refresh derived group permissions if necessary. 4) The user matching functions from bug 162990 will be enhanced to return only visible users. 5) Bug display and processing functions will be given the ability to check user visibility. Processing functions will either have to accept the --anonymous-- user as equivalent to --do-not-change-- (preferred) or else we will have to use --anonymous(nnn)-- with a numeric id. Implementation note: This is very straigtforward except for the user matching function as that could return a large list of users that are not visible but are not up-to-date. To avoid this.... The query today looks like... SELECT id, login, realname FROM profiles WHERE conditions ORDER BY order LIMIT limit It gets to become..... SELECT MAX(groups.changed_when) FROM groups --> $last_change SELECT grantor FROM group_group_map WHERE member IN ($users_group_list) AND isvisibility != 0 --> $users_visibility_groups SELECT id, login, realname,(last_refreshed < $last_change) FROM profiles LEFT JOIN user_group_map ON profiles.id = user_group_map.user_id LEFT JOIN groups WHERE groups.id = user_group_map.group_id AND groups.isvisibility != 0 AND groups.id NOT IN($users_visivility_groups) WHERE criteria AND ((groups.id IS NULL) OR ((last_refreshed < $last_change) AND (user_group_map.isderived = 0)) ORDER BY order LIMIT (limit * 10) Then, as we start to fetch records that match, we accept any records returned where last_refreshed >= $last_changed. As we encounter records where (last_refreshed < $last_change), we call UserCanSeeUser() on those relationships and only include them in the result if they match. As soon as LIMIT records are accepted, the fetch terminates. If the fetch exhausts the returned records before accepting the LIMIT, the confirmation screen will indicate that the wildcard/substring search returned too many rarely-used userids and the user may either a) select from the userids that were returned b) back up and use a narrower search string c) hit reload to continue the search through the next 10*limit potential matches

In response to feedback about the complexity... how's this... In order for user A to see user B, User A much be a member of EACH group that is a "visibility group" of which User B is a member. OR User A must be a member of a group that has been given visibility to EACH "visibility group" of which User B is a member.

Enhancements which don't currently have patches on them which are targetted at 2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. Consideration will be taken for moving items back to 2.18 on a case-by-case basis (but is unlikely for enhancements)

Bug 251837 takes care of the matching issue. This is no longer nearly as important and may never be needed.

(In reply to comment #13) > Bug 251837 takes care of the matching issue. > This is no longer nearly as important and may never be needed. I would like to disagree that this "may never be needed" because email addresses and names can be construed as a personal record which would then mean that Bugzilla is breaking the federal Privacy Act because it is publicizing this personal record with no option for hiding it or warning that this information will be publicized on the Internet. If you're curious or are not familiar with this Act then look at this site... http://www.usdoj.gov/04foia/1974condis.htm. It is exceptionally enlightening. There is another site about the Privacy Act that you may find additionally enlightening and that is... http://www.usdoj.gov/04foia/1974civrem.htm. This other site even includes deadlines for getting something like this fixed from the time that the company responsible for the disclosure of the personal record is notified of the problem in writing (email writing counts in this case) needs to fix the problem within a certain amount of time or requests an extension and also includes a route for someone to seek "relief in the form of monetary damages".

This bug is critical because it makes a security hole into the worlwide mail system.

User visibility exists in Bugzilla for a long time. Being able to see a user but not his email address is another issue. That's bug 163551.