179622 - Flags should use the user's login name instead of its nick

Status: RESOLVED FIXED

(Bugzilla :: Attachments & Requests, enhancement)

Description

[Aleksey Nogin]

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 "[e-mail]" 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.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

#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.

Comment 2

[Asa Dotzler [:asa]]

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

Comment 3

[Aleksey Nogin]

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

Comment 4

[Vlad Dascalu]

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

Comment 5

[Robert Kaiser]

(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 ;-)

Comment 6

[Vlad Dascalu]

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.

Comment 7

[Vlad Dascalu]

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.

Comment 8

[Robert Kaiser]

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

Comment 9

[timeless]

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 [e-mail]
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.

Comment 10

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 11

[Frédéric Buclin]

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

Comment 12

[Frédéric Buclin]

(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?

Comment 13

[Myk Melez [:myk] [@mykmelez]]

Actually it looks like it's bug 218917.

Comment 14

[Frédéric Buclin]

(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 ***

Comment 15

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 16

[Dave Miller [:justdave]]

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

Comment 17

[timeless]

Attachment: i suppose this might work

Comment 18

[Frédéric Buclin]

(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 19

[Frédéric Buclin]

Comment on attachment 271421 [details] [diff] [review]
i suppose this might work

Per my previous comment

Comment 20

[timeless]

Attachment: abbr per lpsolit

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

Comment 21

[Frédéric Buclin]

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 22

[timeless]

Attachment: iterating style over a single file is better than having to mass update

Comment 23

[Frédéric Buclin]

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 24

[timeless]

Attachment: whatever

Comment 25

[Teemu Mannermaa (:wicked)]

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.

Comment 26

[Frédéric Buclin]

Fixed in Bugzilla 5.1 in bug 218917.