Page MenuHomePhabricator

Support alias accounts
Open, Needs TriagePublic


It might be nice to have the concept of an alias account - an account type that functions normally as a user but in most respects refers to another account. Allow me to describe three use cases:

  1. In a large open source project that I am a regular contributor to (not that it is going to be transitioning to Phabricator anytime soon - I made the mistake of championing a conversion from CVS to SVN back in 2006, and don't plan to take on another institutional change, as much as I'd like to), we have a role called the Build Czar (bczar). Nominally this person is responsible for monitoring daily builds, cutting releases, etc. The person holding this role might have elevated privileges; for example in the case of a fabricator based workflow: modify build plans in Harbormaster, edit Herald rules related to projects/repositories, be a gatekeeper to new commits/revisions during the run up to release, etc. Instead of remembering who is the current build czar, it might be nice to be able to just say @bczar in a task/revision/etc to refer to this person. Moreover, changing permissions when handing over the mantle to a new person would be greatly simplified by simply changing the user/users the alias pointed to.
  2. On this Phabricator install, I have to accounts: @wotte and @wrotte. One was created unintentionally, both point to me, but emails go to two accounts. I'd like to be able to point @wrotte at @wotte.
  3. This could be used as a vehicle for implementing T406.

T12658 has some discussion about this in the context of renaming users.

Event Timeline

wotte raised the priority of this task from to Needs Triage.
wotte updated the task description. (Show Details)
wotte added a project: Phabricator.
wotte added a subscriber: wotte.

For (1), it's probably cleaner to create a "Build Czars" project and then give powers to project members. Particularly, this is seamless if you ever need two Czars at the same time (maybe the project has grown, or maybe one is deputized because the other is traveling and only available sporadically, or maybe one is a System Agent account that's hooked up to scripts and the other(s) are humans). Even if your project will never need more than one czar, these more general scenarios seem reasonable for other installs. The permissions also already support doing this (e.g., we don't need a new set of permissions for "users who can update the @bczar alias").

For (2), building some kind of soft-merge / alias probably makes sense, although I think it could be simple: disable @wrotte and leave a note on the profile page, or something like that. I think it's undesirable to have @wrotte remain as a live alias in this case. There are also some security considerations with redirecting email: we can't let an administrator alias an account to their own account, send themselves a password reset email, and then un-alias the account. This is tractable but puts limits on how useful or simple merging can be.

For (3), I think it introduces complexity without much benefit if we don't need it for other reasons.

Another couple of cases here are:

  • VCS usernames (T1731), which the current plan is to add as profile fields.
  • Username aliasing for data entry purposes, e.g. typing usernames from the CLI or @mentioning them. For example, my last name is difficult to spell, and either epriestley or epriestly would resolve to me at Facebook in some contexts. This support was forced by a huge amount of immutable commit data with manually-entered usernames, which is why it mostly does not exist in Phabricator, but we could restore it in some form. I haven't seen a huge amount of demand for it though (although there has been some) and it creates some minor issues when a real epriestly tries to sign up. We'll probably move in this direction anyway, as T4021 plans to add alternate names to projects (#qa instead of #quality_assurance).

For the specific case of "Mention @bczar to notify them", I think we'll probably increase the power of project mentions as projects get an iteration, although I don't have a specific outline for this yet. I agree that this use case seems useful.

A similar case to (2), say someone named John Smith has an internal name john, and his email is, and his username on Phabricator is jsmith, people can mistakenly mention him as john (internal name) instead of jsmith (phabricator username). This can be fairly frustrating especially when they are using arc in command line.

Can we:

  1. support username typeahead in textarea?
  2. show a username suggestion when arc detects that the username typed isn't correct? (e.g., when arc diff fails due to the wrong username)

Hi, I will CC this topic as I have another "good" use of aliases for users.

In our company, we want to merge numerous project into Phabricator, but the naming convention for some project may differ (e.g MatthieuPERIN, mperin and MP123456 (office Id)) and thus when performing import the link between users and commits are sadly lost.

By using an alias I may be able to make link between my former Id and my actual id on Phabricator, for sure It should be checked that aliases are not already assigned (as aliases or users).

It may also provide ans useful workround about missing/lost link when renaming an user ....

Have a nice day :)

Maybe relevant:

In fact, T1731 is almost what we need (except that even in the same repository, some user -shame on them- may have several author Id).

A workaround for SVN is to import repo as git and play with the old-to-new user Id part of the import to manually make matches (impossible for 50+ users project).

thanks for the quick response :)

We've run into a situation where this would be useful in my organization. One person's name has changed recently, but our only option to reflect that in Phabricator is to update their username and thereby disassociate all their past activity. Being able to update the username but add the old username as an alias would solve the issue.

Are there any plans on allowing changing account roles, say from mailing list account to regular user account?

We've been using mailing list accounts to represent single-person (third party) accounts on our install that we needed to communicate with (+ allowed them to create tickets via email in Maniphest). Years later - Spaces were created, and that allowed us finer control.

Now, we'd like to take power of Spaces and allow those people to access our phab install via web, but we wouldn't like to delete/disable their existing accounts, but rather just change their roles.

Or is there any other way we can achieve what we'd like? Thank you!

You can update the phabricator_user.user table and remove the isMailingList flag from the account, something like this:

UPDATE phabricator_user.user SET isMailingList = 0 WHERE username = 'example';

I believe that will just work without requiring additional steps.

Thank you very much, that worked as expected!

eadler added a project: Restricted Project.Aug 5 2016, 5:23 PM