179706 - activity log needs to include full account names for requestees

Status: RESOLVED FIXED

(Bugzilla :: Attachments & Requests, defect, P2)

Description

[timeless]

someone named 'timeless' just got a real review request. there are a few
accounts by that name on bmo, for timeless it's more of a record keeping problem
that a real problem. but there are 118 users found for
http://bugzilla.mozilla.org/editusers.cgi?action=list&matchstr=%5Edavid%40&matchtype=regexp
so when someone views the activity log for any bug where someone asked any of
those david's to review, they won't be able to find out which one was asked. 

another case: brendan's - 8 users found
http://bugzilla.mozilla.org/editusers.cgi?action=list&matchstr=%5Ebrendan%40&matchtype=regexp

Here's a sample bugmail:
http://bugzilla.mozilla.org/show_bug.cgi?id=113202
[e-mail] changed:
           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #94708 [details] [diff]|                            |review?(timeless),

here's how it appears in the bug:
neil: review? (timeless)

and in the log http://bugzilla.mozilla.org/show_activity.cgi?id=113202
[e-mail] 2002-11-12 04:36:37 Attachment #94708 [details] [diff] Flag  
review?(timeless), superreview?(jaggernaut)

Comment 1

[Joel Peshkin]

So here's the root of this particular evil.....

Flags uses a new part of the User hash called 'nick' which is generated as
follows.....

    # Generate a user "nickname" -- i.e. a shorter, not-necessarily-unique name
    # by which to identify the user.  Currently the part of the user's email
    # address before the at sign (@), but that could change, especially if we
    # implement usernames not dependent on email address.
    my @email_components = split("@", $email);
    $self->{'nick'} = $email_components[0];
                                                
This needs to be worked out a whole lot more.  Probably, the correct thing to do
is to make the nicknames settable and searchable.  This would require addressing
the issue of exactly how we keep me from setting my nick to timeless and
timeless from seting his to justdave, etc.....

Comment 2

[Gervase Markham [:gerv]]

Joel: you're overengineering again, dude :-) We don't need to make nicknames
settable and searchable; we just need to make sure we never use nick where
something unique is required, which is the problem here, but only use it for
display.

In my view, the use of nicks has been done not because it's a usability
improvement, but because of lack of space on the attachments screen. That's a
bad reason, and I think this will lead to no end of trouble, and we should ditch
the idea :-)

Gerv

Comment 3

[timeless]

it's ok to do <a title="fullname">shortname</a> if you like for any place which
is constrained for space.

but the log has to be accurate, ideally it'd even survive user renames.

Comment 4

[Bradley Baetz (:bbaetz)]

We use the email on teh edit attachment screen, as of last night.

We just need to propogate that into the activity stuff. If we want to do munging
on show_activity, thats fine.

Comment 5

[Joel Peshkin]

Attachment: patch v1 switches to email instead of nickname

Comment 6

[Joel Peshkin]

Making the change to use email address in the added/removed section.  Templates
could still shorten this to nicknames if desired.

Comment 7

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

>Joel: you're overengineering again, dude :-) We don't need to make nicknames
>settable and searchable;

Actually we do, and it'll be called "username".

>In my view, the use of nicks has been done not because it's a usability
>improvement, but because of lack of space on the attachments screen.

Actually it's for both reasons, and they're both good ones.

Comment 8

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

Comment on attachment 106033 [details] [diff] [review]
patch v1 switches to email instead of nickname

r=myk
a=myk

Comment 9

[Joel Peshkin]

Checking in Bugzilla/Flag.pm;            
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Flag.pm,v  <--  Flag.pm
new revision: 1.5; previous revision: 1.4
done