273548 - Bugzilla sending erroneous "buglist needs attention" email

Status: RESOLVED INVALID

(Bugzilla :: Email Notifications, defect)

Description

[Michael Furmaniuk]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Build Identifier: 

The daily whinemails are being sent out whether or not an account has NEW bugs 
in their account, and the link at the bottom of the emails is listing a bug 
that may or may not belong to the account and is usually not in NEW status.  I 
am currently running 2.16.6, this has started recently I do not recall it 
starting when I first ported over from 2.13.  The NEW URL will not show any 
bugs, and the bug that is listed at the end of this report does not belong to 
the User in the URL and its been closed for a few weeks, each day its always 
the same bug with the same User.  When running the Whinemail query manually I 
get the correct results and never see the bugs at the end show up in the 
query.  I have rebooted the machine to clear out any memory that may be hanging 
around, just in case, but that has not solved the problem.

  Example notificiation is as per the following:

[This e-mail has been automatically generated.]

You have one or more bugs assigned to you in the Bugzilla 
bugsystem (http://bugtracking.fastchannel.com/) that require
attention.

All of these bugs are in the NEW state, and have not been touched
in 3 days or more.  You need to take a look at them, and 
decide on an initial action.
<snip>

To get a list of all NEW bugs, you can use this URL (bookmark it if you like!):

    http://bugtracking.fastchannel.com/buglist.cgi?
bug_status=NEW&assigned_to=[e-mail]

Or, you can use the general query page, at
http://bugtracking.fastchannel.com/query.cgi.

Appended below are the individual URLs to get to all of your NEW bugs that 
haven't been touched for a week or more.

You will get this message once a day until you've dealt with these bugs!

  http://bugtracking.fastchannel.com/show_bug.cgi?id=6072


Reproducible: Always
Steps to Reproduce:
1. Run whinemail each day per cron
2. Check whinemail that arrives

Actual Results:  
Same results as reported in Details

Expected Results:  
Accounts without NEW bugs should not receive whinemail, nor have Closed bugs 
listed as links at the bottom

Comment 1

[Dave Miller [:justdave]]

What's the SQL that gets run at the top of whineatnews.pl?

The query in the 2.16.x distribution is:

SendSQL("select bug_id,login_name from bugs,profiles where " .
        "bug_status = 'NEW' and to_days(now()) - to_days(delta_ts) > " .
        Param('whinedays') . " and userid=assigned_to order by bug_id");

It would be impossible for this query to return bugs that aren't in the NEW
state.  Have you locally modified it?  I'm going to assume that's the case and
close this.  If you can show otherwise, go ahead and reopen this.

Also, check the activity log on the bug in question... it's possible the bug
might have been closed after the mail was sent.

Comment 2

[Michael Furmaniuk]

I have not modified the query string, nor had a need to, as I mentioned the NEW
URL does not show anything.  My SQL is still:

ConnectToDatabase();

SendSQL("select bug_id,login_name from bugs,profiles where " .
        "bug_status = 'NEW' and to_days(now()) - to_days(delta_ts) > " .
        Param('whinedays') . " and userid=assigned_to order by bug_id");

my %bugs;

As I mentioned the end of the email has a bug that is Closed and has been Closed
for awhile.  I cannot find where that Bug is being added and think this may have
something to do with how the Alerts are coming out erroneously, even when I
reset the Bug to Closed that is attached to the emails it still appears on the
Whinemail

Comment 3

[Marc Schumann [:Wurblzap]]

My first thought was that maybe somebody has changed the whinemail parameter to
include some individual bug. But that wouldn't explain whinemails when the
original result set is empty.

Has whineatnews.pl been changed in some way to include more bugs than the
default whineatnews.pl? The site may have chosen to whine at QA contacts who
dally with the RESOLVED->CLOSED transition, for example. Is there something
unusual (another SELECT) after the while(@row=FetchSQLData()) loop?

Comment 4

[Michael Furmaniuk]

I never modified whineatnews.pl, its still in its original implementation.  I've
always seen an individual bug at the end of the notifications, I thought it was
a nice feature; until now.  As the bugs being added at the end do not come back
in the original query I have no way to tell how they are being added, especially
as the only select statement that looks to be run is the SendSQL.

Of course this is under the expectation that:

    foreach my $i (@{$bugs{$email}}) {
        $msg .= "  ${urlbase}show_bug.cgi?id=$i\n"
    }

is only pulling bugs from the original query in the file.

The rest of my whineatnews.pl file is:

while (@row = FetchSQLData()) {
    my ($id, $email) = (@row);
    if (!defined $bugs{$email}) {
        $bugs{$email} = [];
    }
    push @{$bugs{$email}}, $id;
}


my $template = Param('whinemail');
my $urlbase = Param('urlbase');
my $emailsuffix = Param('emailsuffix');

foreach my $email (sort (keys %bugs)) {
    my %substs;
    $substs{'email'} = $email . $emailsuffix;
    $substs{'userid'} = $email;
    my $msg = PerformSubsts($template, \%substs);

    foreach my $i (@{$bugs{$email}}) {
        $msg .= "  ${urlbase}show_bug.cgi?id=$i\n"
    }

    my $sendmailparam = Param('sendmailnow') ? '' : "-ODeliveryMode=deferred";
    open SENDMAIL, "|/usr/lib/sendmail $sendmailparam -t -i"
        or die "Can't open sendmail";
    print SENDMAIL $msg;
    close SENDMAIL;

Comment 5

[Marc Schumann [:Wurblzap]]

Ok...

Please confirm that your scheduler indeed picks up the whineatnews.pl you see
and not some modified copy.

Put the following into whineatnews.pl right before
my $template = param('whinemail'):

   open(BUGLISTFILE, '>buglist.txt');
   print BUGLISTFILE join(', ', @{$bugs{'[e-mail]'}});
   close BUGLISTFILE;

Modify buglist.txt and [e-mail] above to your needs.
If buglist.txt doesn't get created during the daily run, it's either a
permissions thing or you do use a modified copy of whineatnews.pl after all.
Does it contain the bug number in question?

Does the list differ from what you get if you put

   print join(', ', @{$bugs{'[e-mail]'}});
   exit;

instead of the lines above into the file, and you run whineatnews.pl manually
from a command line?

Have the lines

   my %bugs;
   my @row;

been changed so that %bugs gets assigned some initial value?

Comment 6

[Dave Miller [:justdave]]

what's the contents of your whinemail param?

Comment 7

[Michael Furmaniuk]

Turns out the scheduler was picking up a copy that was pointing to an earlier
install...wouldn't have known this without the file modifications.  Thanks for
the help in tracking this down.  I've got it resolved.