Bugzilla user display names are inconsistent
Categories
(bugzilla.mozilla.org :: User Interface, defect)
Tracking
()
People
(Reporter: camelid, Unassigned)
References
Details
Attachments
(1 file)
Screenshot_2020-09-10 1664287 - Allow setting address bar font from about preferences.png
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Firefox/80.0
Steps to reproduce:
I was looking at a bug I filed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1664287
See the attached screenshot.
Actual results:
The name shown in the bug summary is "Camelid" (my display name), but the name shown in the "reporter" section of the bug details is "camelidcamel".
Expected results:
I expected to see "Camelid" for both.
|
||
Comment 1•5 years ago
|
||
Indeed... and I thought we were using the same code to generate display names everywhere for exactly that reason... time to go poking.
|
|
||
Comment 2•5 years ago
|
||
Everything I see shows it should be using your "realname" field everywhere. Wonder if BMO is doing something custom for the header fields...
|
|
||
Comment 3•5 years ago
|
||
Looks like the BugModal extension in BMO&Harmony is at fault here. It's using uses $user.nick instead of $user.real_name for the fields in the header. Bugzilla's default templates are using $user.real_name in all cases.
Using $user.nick is correct in this context - the goal is to use the short form of the name; this falls back on extraction from the email address if a nick hasn't beeen set using the : prefix.
ie. we want to display justdave not Dave Miller [:justdave] (justdave@thunderbird.net) in that location.
The real fix is to make your nickname a separate field making it obvious how to set it, rather than the : prefix insider knowledge. I'm sure there's a bug for this already but I can't find it.
Camelid - you can work around this by changing your real name to :Camelid.
|
Reporter | |
Comment 5•5 years ago
|
||
Hmm, okay thanks. Yeah, I wondered why so many people had :{nickname} in their names!
|
||
Comment 8•5 years ago
|
||
I get the reasoning of using $user.nick, but If no insider nickname is set, shouldn't it more sense to fallback to their real name instead of email address part, which often makes no sense?
Also, I'm not sure why $user.real_name of Dave in your example has the full email address shown, mine don't have it (as you can see right here).
I think the bottom line is, the "shorter form" should be easily recognized to be the same person in "long form". And currently it's not, for people don't have their "insider nickname" setup (most of people?).
(In reply to fireattack from comment #8)
I get the reasoning of using $user.nick, but If no insider nickname is set, shouldn't it more sense to fallback to their real name instead of email address part, which often makes no sense?
The problem is real names can be very long; eg. Dave's is 50 chars.
While it's possible to work around this in various ways (eg. truncating the real name), the real fix (ie. what we should do rather than this bug) is to make the "nick" either a real field, or presented as one when editing your profile.
Also, I'm not sure why $user.real_name of Dave in your example has the full email address shown, mine don't have it (as you can see right here).
Dave's real name contains literally Dave Miller [:justdave] (justdave@thunderbird.net), probably to make that account discoverable when searching for either his thunderbird or bugzilla addresses.
Description
•