Closed Bug 256762 Opened 20 years ago Closed 20 years ago

flag request email doesn't use emailsuffix


(Bugzilla :: Email Notifications, defect)

Not set



Bugzilla 2.18


(Reporter: dylan, Assigned: Wurblzap)



(2 files)

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7) Gecko/20040809 Firefox/0.9.3
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7) Gecko/20040809 Firefox/0.9.3

Bugzilla/ using template/en/default/request/email.txt.tmpl fails to
append emailsuffix to to_email.

Reproducible: Always
Steps to Reproduce:
Set emailsuffix to
Have users login with just user names.
Request a flag to be set from someone.
Actual Results:  
Email didn't get sent correctly: went to user (without email suffix).

Expected Results:  
Email should have been sent to user@emailsuffix.
Attached patch PatchSplinter Review
Btw, it seems to me that the votesremoved code in suffers from the
same ailment. Is there a bug for this?
Attachment #157157 - Flags: review?
Seems to be happenning here too.
Assignee: justdave → marcschum
Ever confirmed: true
Comment on attachment 157157 [details] [diff] [review]

Looks correct (but I haven't tested on my tree). 

Note that seems to have a similar issue at least. I suspect does as well.
Attachment #157157 - Flags: review? → review+
Raising severity as this results in an inability to use flag notifications with
Severity: minor → major
Flags: blocking2.18?
Flags: approval?
Flags: approval2.18?
Flags: blocking2.18?
Flags: approval?
Flags: approval2.18?
Flags: approval2.18+
Flags: approval+
Checking in;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/,v  <--
new revision: 1.21; previous revision: 1.20

Checking in;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/,v  <--
new revision:; previous revision:
Closed: 20 years ago
Resolution: --- → FIXED
Target Milestone: --- → Bugzilla 2.18
kiko, Marc, comment #3: can you confirm that the problem exists in or, or/and open a bug/bugs about that one in order to keep it on the

Follow-up bugs are bug 258709, bug 258711 and bug 258712.
Perhaps i'm insane, but this patch does not work for me. I applied against 2.18rc2.

Further, i don't see how it can work. I'm attaching my own patch that does work
for my installation. Comments as to what's going on are appreciated.
I looked at the patch in comment 3, and after hitting my head against it for a
while, finally realized that it's in an if block:

if ($flag->{'target'}->{'bug'}->{'restricted'}
        || $flag->{'target'}->{'attachment'}->{'isprivate'})

Since, in my case, it's neither private nor restricted, this isn't helping.

Tyler's fix looks much better.

Um...I can't reopen this bug.  Someone?
(In reply to comment #10)

Peter, I think the patch is correct. It does not change the fact that cc list
members do not get a notification under certain conditions. What it does change
is that if they do get a notification, then the emailsuffix is appended to their
logins to build their full e-mail addresses.

Is it possible that what you're seeing is a different bug?
I just checked the latest CVS, to make sure I wasn't missing anything:

Assume 1. the bug is not restricted, 2. the attachment is not private, and 3.
that the flag does have a 'cc_list' (say, "pkay").  All these conditions are met
in my installation.

In sub notify, the if() {} block that contains
    push(@new_cc_list, $cc.Param('emailsuffix'));
is not executed (1 and 2 above), $flag->{'type'}->{'cc_list'} is not updated,
and Bugzilla happily tries to send e-mail to "pkay" (3 above) - which bounces,
as there is no local user "pkay".  I can show you the bounce messages, if you
like :)
Now I get it :)

The thing is that flags' cc lists are not bugzilla logins but simple free e-mail
addresses (see
This was new to me, I admit.
This means that
 - my patch is wrong (I filed bug 277389 to correct that) and
 - you should put full e-mail addresses into your flag's cc list field.
I guess this should be "INVALID" not "FIXED", huh?

That took me by surprise, too - I hadn't read the manual, myself.

Thanks, Marc!
(In reply to comment #14)
> I guess this should be "INVALID" not "FIXED", huh?

Requestee and setter still need the emailsuffix, the patch is right on that account.
Even without that, there is a patch on this bug which has been checked in, so
the bug is, by definition, fixed :/
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.