278906 - If mail not sent previously for bug, subsequent change sends "new bug" style email

Status: RESOLVED INVALID

(Bugzilla :: Email Notifications, defect)

Description

[Keith Tyler]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

While manually restoring our BZ buglist by hand, I disabled processmail (this
was 2.16.7, now since upgraded to 2.18 release) to prevent a flood of email to
all my users.

It seems that after this fact, with any bug that was entered while processmail
was disabled, any change to the bug will trigger "New Bug" notifications to be
sent out (dumping all comments), instead of the normal change-notice notification.



Reproducible: Always

Steps to Reproduce:
1. Disable processmail (or BugMail.pm) (e.g. add "exit(0);" to top)
2. Add a new bug
2. Make changes to bug
3. Re-enable processmail
4. Make change to bug 

Actual Results:  
Instead of a change notification email, Bugzilla will send out a new-bug
notification email. All comments are included (both old and new), no "change
box" is included.

Expected Results:  
Since the trigger was a bug change, and not a bug creation, a bug change
notification style email should have been sent.

Apparently the notification process does not actually use the action performed
on the bug to determine whether it should send a "new bug" notice or not, but
instead makes the distinction based on the history of email delivery for that bug.

Comment 1

[Max Kanat-Alexander]

Yeah, this behavior is actually intentional, from what I know. The way that
Bugzilla mail works is that it looks at the last-sent time of comments, and
sends out all comments that haven't yet been sent.

Bugzilla generally doesn't expect you to have to restore the entire bug database
by hand for some reason.

Comment 2

[Stephen Lee]

Reporter's bugzilla database would be failing sanitycheck.cgi with something 
similar to the following near the bottom:

Checking for unsent mail 
Bugs that have changes but no mail sent for at least half an hour: [list]
Run processmail rescanall to fix this


If you follow the advice of sanitycheck.cgi, this will create the deluge of 
mail that you were attempting to avoid.

The easiest way to get everything up to date is the following SQL query:

UPDATE bugs SET lastdiffed=delta_ts
WHERE lastdiffed < delta_ts AND delta_ts < date_sub(now(), INTERVAL 30 minute);

(based on the same WHERE clause in query used by "processmail rescanall" and 
sanitycheck.cgi)


Omit the second condition (after the AND) if you also want it to clear changes 
within the last half hour and know that no bug updates are currently occurring 
for which you DO want mail.


For the record, a better way to disable mail from being sent is to temporarily 
change the newchangedmail site param, so that it sends to a dummy mailbox (or 
to no mailbox) rather than the intended recipient. This way, processmail still 
runs and updates the "lastdiffed" time, but does not actually send mail.

Comment 3

[Olav Vitters]

exit(0) is not the way to disable mail delivery. Use SQL in comment 2 to fix the issues you are seeing. In Bugzilla CVS (I think 2.20 as well) there is a mail_delivery_method. You can set that to 'none' to disable mail delivery. This will ensure the lastdiffed is correctly updated (e.g. you will not see the initial bug creation anymore).

Marking invalid as the behaviour you are describing was not caused by Bugzilla (incorrect modification to Bugzilla) & we have a nice way to do this correctly.