Currently, the attachment flags are listed with the local (e.g. pre-@) part of an email address. This is a reasonable default, but in some cases something better is needed. I am currently use "mozilla-bugs@nogin.org" address for bugmail. This means that the flags I set are listed as "mozilla-bugs: ..." which looks pretty stupid and is not too informative. I see the following alternatives: 1) Use the Real Name field, only use the pre-@ when real name is not set. 2) Use the full email. 3) Give user a choice (in preferences) as to whether use short name, or (1), or (2) 4) Make the string user-editable (in preferences), possibly with the pre-@ being the default.

#4 is the rigth solution. Bugzilla should let users set usernames distinct from their email addresses and use them in lieu of those addresses in a number of places including flag setter strings.

How would these "user names" be any different from realname which can already be set by the user?

I'll be shorter. But IMHO just using real names would probably aslo be a reasonable solution.

*** Bug 178856 has been marked as a duplicate of this bug. ***

(In reply to comment #2) > How would these "user names" be any different from realname which can already be > set by the user? well, it might not look very nice to have the flag field state something like "James Tiberius Kirk (away until stardate 4863.2): review-" with a user-editable string that can fit the usual nicks or something similar, we'd probably have "captain: review-" in that case, and we also can get a bunch of those "bugzilla: superreview+" changed to "sicking: superreview+". I'd go for that field defaulting to what we do now (pre-@ part of the email address) if empty, so we have a nice migration path as well ;-)

The issue is that the "Real Name" field is used for other purposes, like the "away status". We should have a field especially for that, called "away status", and keep the "Real Name" field for flag requests. Then it would read: "James Tiberius Kirk: review-" (captain does approvals anyway :) ). When displaying who posted the comments, probably the name could be concatenated with the away status.

The issue with using the real names thought would be identity spoofing. I can set my real name to "David Miller" or "justdave" and for most people I would act in his behalf. We need some sort of credential that should be guaranteed to be unique across the system. Either introduce an "username" field, that is guaranteed to be unique, or display (for now) the complete email address.

Yes, a short and really unique identifier (username, whatever) might help us in many regards, I'd think. We could even accept that name for all those CC, assignment, flag request and similar fields and have something simpler to deal with than the full email address we use currently. And it would help us keeping those flag displays short and simple, while still telling really who set it :)

blah, just bleed the userid or let each user pick their own nicknames for other accounts. the nicknames would be bound by userid so when justdave@bugzilla.org changes his email address, my bound nickname 'justdave' will still point to him. when displaying people, prefer user bound nicknames over everything else, and generate some css / markup so that it's clear we picked a bound nickname. also provide some css / markup so that you can distinguish between an email address and a realname.

There's a bug on decoupling usernames from email addresses, although I can't find it right now. We should do that, letting users choose their own usernames, with uniqueness across the installation the only requirement, and then display the username instead of the user part of the email address in flags.

*** Bug 181235 has been marked as a duplicate of this bug. ***

(In reply to comment #10) > There's a bug on decoupling usernames from email addresses, although I can't > find it right now. Maybe bug 34122?

Actually it looks like it's bug 218917.

(In reply to comment #13) > Actually it looks like it's bug 218917. Seems to, yes. Marking this one as a dupe as the other one already has a patch. *** This bug has been marked as a duplicate of 218917 ***

Actually, that bug will implement arbitrary usernames, but it won't necessarily immediately use them in all places in the codebase, so this bug is still useful and separate from that one.

*** Bug 305566 has been marked as a duplicate of this bug. ***

(In reply to comment #17) I don't want to see more links pointing to the email address. Why not using <abbr> or <acronym> instead?

Comment on attachment 271421 [details] [diff] [review] i suppose this might work Per my previous comment

note that right now identity is actually buggy (see some other bug / patch of mine)

Comment on attachment 273350 [details] [diff] [review] abbr per lpsolit >+ <abbr >+ title="[% flag.setter.identity FILTER html %"> Missing ] after the 2nd %. >+ (<abbr> >+ title="[% flag.requestee.identity FILTER html %]"> The title attribute must be inside <abbr>. Also, is there any reason you do it for attachment flags, but not for other flags? Please add an entry for abbr in CSS files to hide their decoration. The attachment table now looks ugly with all the requester and requestee names being underlined. You would have seen it yourself if you tested your patch (as well as all the comments above). ;)

Comment on attachment 273542 [details] [diff] [review] iterating style over a single file is better than having to mass update >+ (<span title="[% flag.requestee.identity FILTER html %]"> >+ [% flag.requestee.nick FILTER html -%] >+ </span>) You definitely seem unable to *test* your patches before attaching them. -%] doesn't prevent a whitespace to be added before ). Before attaching the next one, be sure to test it or find another reviewer.

Comment on attachment 275309 [details] [diff] [review] whatever >Index: template/en/default/attachment/list.html.tmpl >=================================================================== >+ <span title="[% flag.setter.identity FILTER html %]"> >+ [% flag.setter.nick FILTER html -%] >+ </span>: There's now an extra blanks after the nick. >+ (<span title="[% flag.requestee.identity FILTER html %]"> >+ [% flag.requestee.nick FILTER html -%] >+ </span>) Same here. >Index: template/en/default/bug/edit.html.tmpl >=================================================================== >- [% val FILTER truncate(size) FILTER html %] >- </span> >+ [% val FILTER truncate(size) FILTER html %]</span> Why this change? Doesn't seem to be relevant to this bug. >Index: template/en/default/bug/show-multiple.html.tmpl >=================================================================== >+ [%+ IF flag.status == "?" && flag.requestee %] >+ (<span title="[% flag.requestee.identity FILTER html %]"> >+ [% flag.requestee.nick FILTER html %]</span>) > [% END %][% ", " IF not loop.last() %] There's now an extra blank before comma when there's no requestee. Probably caused by the extra linefeed that's now generated. >Index: template/en/default/flag/list.html.tmpl >=================================================================== >- [%- type.name FILTER html FILTER no_break -%]</label> >+ [%- type.name FILTER html FILTER no_break %]</label> Changes to this file seems to be missing. Now only logged-out case of bug flags is handled and logged-in case remains unchanged.

Fixed in Bugzilla 5.1 in bug 218917.