Page MenuHomePhabricator

Make real name optional on user accounts
Closed, ResolvedPublic


I can't seem to find anywhere I can turn this requirement off. grep'ing the Phabricator code base shows that this field is only really used in a couple of places (most places seem to show the username).

Is there a way we can make this field not required? (Our users won't be directly using Phabricator, so it doesn't make sense for them to provide a real name on registration)

Event Timeline

hach-que updated the task description. (Show Details)Apr 3 2014, 10:15 AM
hach-que added a project: Phabricator.
hach-que added a subscriber: hach-que.
hach-que created this task.
hach-que assigned this task to epriestley.
hach-que raised the priority of this task from to Needs Triage.

How are you creating user accounts? Through the normal registration workflow (but, like, reskinned or something), or some kind of magic?

I think you can listen for PhabricatorEventType::TYPE_AUTH_WILLREGISTERUSER and then do:

$profile = $event->getValue('profile');


That will remove the field from the form, and cause everyone to register with an empty real name by default. A handful of places in the UI may look a bit off (e.g., show username () when they would normally show username (Real Name)) but we could probably deal with those on a case-by-case basis.

I'm using the __pageview patch and routing another domain through Nginx to
the login / register pages. You can see it at

I ended up using Javascript to hide the row and set the field to "Unearth
Player", but the hook to hide the field sounds like a better solution in
the long term.

(It'd still be nice to have this as a config option though)

qgil added a subscriber: qgil.Apr 18 2014, 4:12 PM

Our users (used to MediaWiki and Bugzilla) also expect Real Name to be an optional field. Visible during registration, but not required.

Currently Real Name is a required field through the default registration process, even if just adding a space will get you through. With such a low barrier, and no hard dependency on Real Name anywhere in Phabricator, it would be consistent to define this field as optional by default.

fwiw link to our original request:

qgil added a comment.Apr 18 2014, 6:01 PM

By the way, "Display Name" would probably be a better string than "Real Name". More flexible and friendly, less official and bureaucratic.

It's not a display name though, that would be confusing. Your username is what's displayed in 99% of the UI.

qgil added a comment.EditedApr 18 2014, 7:00 PM

EDITED, sorry, I misunderstood your comment.

You are right. Then why not just "Name".

This might sound too picky, I'm just summarizing eternal discussions in the MediaWiki and Wikipedia projects with different people having different and strong opinions about privacy.

Anyway, I didn't want to deviate from the original point. Making the field optional would solve most of the problem.

asherkin closed this task as Resolved.Apr 18 2014, 7:01 PM

Right, which is exactly why I disagree with renaming Real Name to Display Name... as it's not what is displayed everywhere.

asherkin reopened this task as Open.Apr 18 2014, 7:02 PM

I have no idea why that got closed.

Some general thoughts on this (@btrahan / @chad might have input too, various flavors of this have come up in the past as having wide-reaching product implications):

Even though users can type garbage in, requiring the field seems to be effective at getting real names entered: in practice, most people seem to type their real names (although it's hard to tell how much of this is because OAuth is pre-filling them and they just don't remove them). If the behavior we saw was most people typing a space or garbage, I think it would be an easier decision to make this optional, but even on this install (where most users have almost no incentive to provide a real name) most users seem willing to provide it, or at least provide some reasonable approximation (a nickname, first name + last initial, etc).

I think having real names in the system is valuable, especially for companies. For example, I'd have no idea who, e.g., gc3 was at Facebook without being able to look up his full name. In these cases (where there is no expectation of anonymity), I think requiring a real name is mostly a guard against laziness. As a particular example, we also allow users to add profile pictures, but don't require them. I think profile pictures are at least as valuable as real names, but I've seen several installs where very few users have uploaded a profile picture (some of these were from a while ago, when it was more difficult to upload pictures). I'd generally support prompting users to add a profile picture at some point, if we had a reasonable mechanism for it.

That said, I think the anonymous/open source case is a reasonable argument for making this optional at least some of the time. I hate adding configuration, but for other installs I think the "laziness guard" effect of requiring this field might be strong enough to justify making it an option rather than just always making this field optional for all installs.

Some technical notes:

  • the field is currently optional when actually editing a profile; it should be made consistent.
  • rendering users full names should omit the () if they have no real name: currently we get alincoln () on profiles and similar. This should mostly be in PhabricatorObjectHandle, but we might have a scattering of callsites building these manually.
  • there are several name rendering modes for email, one of which uses only the real name; this should use the username if a user has no real name. One of these modes uses both components, and should apply the same () rules as above.

I think config with the default as required is the right call. I think usage by private companies will vastly outnumber open source installs for awhile and this is the right default for them. Otherwise, its worth supporting, if for nothing other than existing engineering groups that are used to anonymity.

While we're in there, let's make full name on system agent accounts always optional. :D

For me, in the context of using Phabricator it makes sense for it to be required. I don't really mind have it as a required field when signing up for Phabricator.

My use case is a little weird, since I'm using the Phabricator infrastructure for storing user accounts for playing a game (because I want the same account to be used for reporting bug issues, etc). In a non-Phabricator context, real name requirement doesn't make sense, especially since the user isn't going to be interacting with Phabricator on a regular basis.

I know this is a weird use case, but given the low number of call sites that actually use the real name field, there's nothing in the software itself that actually requires data in this field.

epriestley reassigned this task from epriestley to lpriestley.

Add a configuration option: Add a new configuration option for this in PhabricatorUserConfigOptions, something like user.require-real-name. Default it to true. To test this, it should appear in Config -> User Profiles and be editable.

Respect it when registering accounts: If the setting is off, don't require a real name be entered in PhabricatorAuthRegisterController.

Fix UI rendering: PhabricatorPeoplePHIDTypeUser->loadHandles() produces nonsense if a user has no real name, alincoln (). Instead, it should omit the parentheses fi there's no real name. PhabricatorMetaMTAActorQuery->getUserName() has a mode where it returns the real name. If the real name is empty, it should return the username instead.

Cleanup: There are kind of a lot of callsites where we're using getRealName() to build an alincoln () string. These should generally get merged into way fewer callsites and/or fixed. These can happen in followup diffs, they don't break anything major. Some of them are probably obvious/easy but some of them may be tricky.

epriestley triaged this task as Normal priority.May 6 2014, 12:46 PM
lpriestley edited this Maniphest Task.May 9 2014, 5:06 PM
lpriestley edited this Maniphest Task.May 12 2014, 4:52 PM
lpriestley closed this task as Resolved.May 12 2014, 4:52 PM

Closed by commit rPdfcccd4cb882.