There is no way to search for users being in no group, or being in system groups such as canconfirm and/or editbugs only. Such users should be visible in all cases. If you want to hide them, add them to a group used for bugs. We already had many bugs about the fact that the admin couldn't see his users. So it's more annoying than helpful.
I like the idea of having a bz_everybody group which everybody is a member of. By default, this group would be visible to admin and editusers groups members. This would allow us to keep the current (working) mechanics, and it would allow us to treat system groups, other non-bug groups and bug groups equivalently.
That sounds like the best solution.
Looks like what I said in comment 0 is wrong about system groups. System groups are visible if the "Visibility" checkbox is checked for these groups. This left us with users with no privs. /me thought system groups were visible by the admin group by default.
Updating the summary of the bug accordingly.
*** Bug 303492 has been marked as a duplicate of this bug. ***
*** Bug 307413 has been marked as a duplicate of this bug. ***
LpSolit reports that this also prevents users privs from being edited, at all, if they are new users. So that's a blocker.
When an admin creates a new user account, this account has no privs by default (well, unless you let .* as the default regexp for some groups, which isn't the case on b.m.o for instance), but changing privs for this user account returns the following error: "Sorry, there are visibility restrictions on certain user groups, and so you are not authorized to modify the user you specified." In other words, you cannot edit privs for users being in no group (you have access to). Workaround: disable usevisibilitygroups! Heh :)
I have tried to disable usevisibilitygroups, and this did not work for me. :(
Now that bug 303784 is fixed, users with 'editusers' privs can override visibility restrictions and see all users, even those being in no group. Do we want something more about editing users? If not, then we should close this bug. I think that this bug is no longer a blocker. joel?
Fixed by bug 303784, so it's not a blocker anymore.