255913 - Mailto link on show_bug.cgi ignores emailsuffix parameter

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, defect)

Description

[Jim Babcock]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115

The mailto link for the Reporter field in show_bug.cgi actually points to the
username. If the emailsuffix parameter is set, it should be appended.

There are many other places where this is a problem as well, but it's clearly
wrong with the mailto link. The obvious fix is to replace
sub email { $_[0]->{login}; }
with
sub email { $_[0]->{login} . Param("emailsuffix"); }
at Bugzilla/User.pm line 127.

But someone would have to check for other code using this function and appending
the suffix itself, which would cause the suffix to be appended twice, or using
email() when it should be using login().

Reproducible: Always
Steps to Reproduce:
1. Go to the Edit Parameters page
2. Set emailregexp=^[^@]+$
3. Set emailsuffix=@[hostname]
4. Create an account [username] and use it to submit a bug
5. View that bug with show_bug.cgi
Actual Results:  
The Reporter field is a mailto: link pointing to [username]

Expected Results:  
The Reporter field should be a mailto: link pointing to [username]@[hostname]

Comment 1

[Shahar Talmi]

This bug also exists in version 2.18rc2.
I'm running this version on Win2K3.

Shahar.

Comment 2

[Marc Schumann [:Wurblzap]]

Attachment: Make Bugzilla::User::email() return the email address instead of the login

This is what is suggested in comment 0. Luckily, duplicate emailsuffix
appending does not happen anywhere.

Comment 3

[Tobias Burnus]

Comment on attachment 158408 [details] [diff] [review]
Make Bugzilla::User::email() return the email address instead of the login

I'm not sure whether this should be
   name <login> or name <email>
in 'sub identity'. Currently, it is:
    if (!defined $self->{identity}) {
	$self->{identity} =
	  $self->{name} ? "$self->{name} <$self->{login}>" : $self->{login};
    }

In principle, I'm really in favour of having the complete email address.
Otherwise r=burnus

Comment 4

[Marc Schumann [:Wurblzap]]

(In reply to comment #3)
> I'm not sure whether this should be
>    name <login> or name <email>
> in 'sub identity'.
> 
> In principle, I'm really in favour of having the complete email address.

I would like to keep this question out of scope of this bug...
Currently the identity shows the login, and the patch retains that behaviour.

Comment 5

[Dave Miller [:justdave]]

Comment on attachment 158408 [details] [diff] [review]
Make Bugzilla::User::email() return the email address instead of the login

I agree the identity thing is outside the scope of this bug.  That can be
another bug.  This is definitely the right thing to do for User->email()
though.

Comment 6

[Dave Miller [:justdave]]

As long as this doesn't break anyplace using ->email that's not really expecting
an email, this should be fixed on the 2.18 branch as well.

I assume you need someone to check in for you?

Comment 7

[Marc Schumann [:Wurblzap]]

(In reply to comment #6)
> I assume you need someone to check in for you?

Yes... Would you please be so kind?

Comment 8

[Dave Miller [:justdave]]

Checking in Bugzilla/User.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/User.pm,v  <--  User.pm
new revision: 1.30; previous revision: 1.29
done

Comment 9

[Marc Schumann [:Wurblzap]]

(In reply to comment #6)
> As long as this doesn't break anyplace using ->email that's not really expecting
> an email, this should be fixed on the 2.18 branch as well.

This doesn't break anything on 2.18.

Comment 10

[Dave Miller [:justdave]]

doh.

2.18 branch:

Checking in Bugzilla/User.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/User.pm,v  <--  User.pm
new revision: 1.20.2.1; previous revision: 1.20
done

Comment 11

[Dave Miller [:justdave]]

(In reply to comment #9)
> (In reply to comment #6)
> > As long as this doesn't break anyplace using ->email that's not really
> > expecting an email, this should be fixed on the 2.18 branch as well.
> 
> This doesn't break anything on 2.18.

bzzzt.  :)   See bug 264868.