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 jsmith@email.com, 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:

• T3725: Using keyword @ to address users does not autocomplete names discusses adding a Javascript autocomplete while typing comments.
• T1731: Allow users to set their VCS names discusses letting users specify additional names which are theirs in SVN/Git/Mercurial, so commits link up correctly.

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 :)

T7908 is somewhat similar.

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!