28458 - using new email system, "New" bugs do not have CC or QA contact

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, defect, P3)

Description

[Alec Flett]

Just a minor nit... when an email notification for a new bug arrives (i.e. not a
changed but bug a new one) the list of headers does not include the CC list or
the QA contact. This would be useful information to have, and sometimes I wonder
who else is on the CC

I'm not in QA but I would imagine this would also make it difficult to know if
you're getting this notification because you're the QA contact or because you're
on the CC...

I realize there are lots of headers already, but you could probably remove some
of them because they are not even in the "Enter Bug" form, such as: keywords,
Resolution, and status whiteboard. Those fields can only be accessed when you're
changing an existing bug.

By the way, I LOVE the new email notification system :)

Comment 1

[Terry Weissman]

[e-mail] is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)

Comment 2

[Dave Miller [:justdave]]

This is an easy fix, and something I've been noticing, too.  It's annoying.  
Should this be a 2.12?

Comment 3

[Stephan Niemz]

Adding default QA contact to all open Webtools/Bugzilla bugs lacking one.
Sorry for the spam.

Comment 4

[Jesse Ruderman]

New bugs also show status whiteboard, keywords, and resolution, even though 
those fields are always (?) empty.

Comment 5

[Jacob Steenhagen]

Looking at the code in processmail it appears that the decision to show a field
in the new bug notification is made by checking the value of fielddefs.mailhead
(1 means show, 0 means don't).

I could be wrong about that as I only looked at it for about 30 seconds, but If
I'm right changeing which fields appear is a simple change to the db.
Unfortunately, simple db changes are on hold until the oldmail is removed
(because of the shadow directory regeneration in ./checksetup.pl).

Comment 6

[Dave Miller [:justdave]]

since we decided oldemailtech is going away in 2.14 precisely for that reason, we 
can probably do this at the same time.

Comment 7

[Jacob Steenhagen]

Attachment: Change mailhead values

Comment 8

[Jacob Steenhagen]

The previous patch changes the values of mailhead where they're defined in
checksetup.pl for status_whiteboard (turns off), keywords (turns off),
resolution, (turns off), and cc (turns on).  These values are updated in the DB
everytime checksetup.pl is run.

It also adds a routine to doeditparams.pl to update the mailhead value for
qa_contact based on the useqacontact param.

To include qa_contact in the New: e-mails for a running system, either the
useqacontact parm has to be turned off then back on or the following SQL
statement should be run:

    UPDATE fielddefs SET mailhead = 1 WHERE name = 'qa_contact';

Comment 9

[Dave Miller [:justdave]]

Looking over the processmail code, my take on it is that except for a couple 
exceptions (like CC and dependencies, because they're handled differently) the 
mailhead values are used to determine whether processmail should report changes 
on them, too.  So by clearing the mailhead values for status whiteboard and 
resolution, you are preventing processmail from ever reporting changes to these 
fields.

Comment 10

[Jacob Steenhagen]

I just looked at the code again.  What it seems to do is pull the mailhead value
from the DB and put it into %defmailhead (line 90).  It then passes the hash to
NewProcessOnePerson (line 264).  NewProcessOnePerson uses this hash to set the
$head variable (line 644).  Then the $isnew variable determines if $head or
$difftext should be placed at the top of the e-mail (line 679). AKAICT, that's
all mentions of 'mailhead' (or the variable it gets placed into/is used to
determine which code to run).  fgrep shows that 'mailhead' only appears in
processmail and checksetup.pl.

All line numbers are based on r1.63 of processmail

Comment 11

[Zach Lipton [:zach]]

Why use   in the print statement?

Comment 12

[Jacob Steenhagen]

Hmm... I'm sure there was a reason, but I don't remember it :)

Comment 13

[Tara Hernandez]

Dave/Jake -- Patch is up on Landfill.  Please play with it there and make sure
you're in agreement on the implementation.  It looks okay to me on cursory
inspection, but I'd like Dave to make the final call.

Comment 14

[Dave Miller [:justdave]]

ok, played on landfill, it does indeed have the fields in the changemail that are 
taken out of the mailhead list.  So all is cool.

r= justdave

checked in.

Comment 15

[Dave Miller [:justdave]]

Just realized that AddFDef in checksetup.pl will replace your fielddefs every 
time you run it.  This effectively nullifies any change made in editparams.pl if 
you update, which completely eradicates the QA Contact from showing up unless you 
turn QA Contacts off and back on every time you update...

Comment 16

[Jacob Steenhagen]

Now that bug 85734 is landed, qa_contact can be turned on as a mailhead and if
it's blank (which it will be if Param('useqacontact') is off) it won't be
included in the message.

Comment 17

[Jacob Steenhagen]

Attachment: bugfix v1

Comment 18

[Dave Miller [:justdave]]

r= justdave

checked in.

Comment 19

[Dave Miller [:justdave]]

Moving to Bugzilla product