Page MenuHomePhabricator

Identifying users by e-mail
Closed, DuplicatePublic


Perhaps related to T8067 , but our use case may be slightly different.

One problem we are seeing is that - once an account has been approved - it is impossible to see who that account is.

So, for example: Someone registers the username "myname" with the e-mail "". Once that username has been registered, there is no way for us -as administrators - to find out where the "myname" username comes from. This is a problem, because as an administrator you sometimes you want to follow up on a user's registration later.

Another use case is that we want to create a policy/project group that is limited to verified users in the domain. Since we can't see the e-mails, though, we have no way of knowing whether "myname" is or In practice, the only way we can currently do this kind of stuff is to send out an e-mail to everyone and ask them to join manually - which doesn't really work.

Obviously, e-mails are not something we want to spread around, but it would be a great help if it were possible for administrators to see the e-mail addresses of users in the People interface; even better if they can be retrieved through conduit by users with admin credentials.

Event Timeline

michaeloa updated the task description. (Show Details)
michaeloa added a project: People.
michaeloa added a subscriber: michaeloa.

Please see Requesting Features for how to request features in Phabricator. Specifically we're interested in the core problem you are having day to not, and not anticipated problems.

Not sure why you think the above describes an anticipated problem. To be clear, this is an actual problem that we have today (and have had pretty much since Day 1 when we adopted Phabricator, but we hoped the addition of the Spaces module would help solve it).

We have an open Phabricator installation, where anyone is allowed register - much like this one (we're a public Institution doing mostly OSS, so we aim for transparency in what we do).

We often have to deal with confidential information wrt projects, however. Actually secret information isn't allowed on this kind of server, of course; the most common use-case is the restriction just to prevent open public dissemination; i.e., info or data that should be accessible to all employees, but not available to the public in general.

Another concrete use-case (not related to Spaces): we want all Projects to be visible to all Employees (they need to know what is happening at their workplace); but certain projects should not be visible to non-employees (for various reasons - e.g., security).

In theory, these issues can be handled using Policy and Spaces. In practice, we have the problem is that there are no administrative tools that allow us to effectively identify users once they've been added to the system since all details are hidden - even from admins. Thus we have no way of assigning a large number of users to policy groups post-registration, short of approaching each user on an individual basis. We have 400 employees, and while only a minority are on Phabricator, it's still too many to make this sort of manual, individual user management practicable.

Hope the above clarifies the problem.

I mentioned anticipated because you mentioned catching spammers with such a tool. Is this actively happening? We're probably the largest (by user reg) open install, and haven't had any spam concerns. If it's a problem, then that should be a different ticket.

Bucketing people into roles upon registration is T4103, specifically T4103#62986 has some spec and scope.

We don't advertise our site except to people who are in the field, but we do still get spammers; probably about 1-2 attempted registrations per month on average. So far I think we've managed to catch them all in the approval process, usually by vetting the e-mail address.

My concern is not about catching spammers though, but rather the administration of existing users. T4103 would be great to have in a new Phabricator install, but it doesn't help existing installations, which is our problem. It is the main reason why we haven't started using Spaces for anything.

You should definitely follow up on the other task with your use cases. Ideally we want to group many similar feature requests so we can architect a single system to cover all or most needs. As that task is still being planned, it's better to comment on it now so those needs can be factored in.