Since no one volunteered to explain the notification rules, I had to read the source code to find out since the redundant notifications were driving everyone crazy. I'll post my findings for others. It does appear that two different individuals implemented notifications because they are in two separate modules: bug_api.php and email_api.php.

There are three notification categories in bug_api.php that are always sent out:

bug assignment change, status change, and updated (any field).

I have commented these out. Our projects are one-person projects so assignments don't change.

The status change and update notifications are duplicate, and also usually occur when someone

reporting a bug forgets to make a selection. The developer doesn't need to be bothered with

administrative fixes to the form; the notes are what matter.

These are the roles eligible for notification (from email_api.php):

#

'reporter': the reporter of the bug

'handler': the handler of the bug

'monitor': users who are monitoring a bug

'bugnotes': users who have added a bugnote to the bug

'threshold_max': all users with access <= max

'threshold_min': ..and with access >= min

These are the events eligible for notification (from email_api.php):

#

new

bugnote

resolved (was "status_resolved") -- to be fixed in 19.0

closed (was "status_closed") -- to be fixed in 19.0

reopened

assigned

deleted <-- This is the one item that is not on the Preferences menu

Also, a bug causes delete notifications to be sent to every project contributor

when the project is deleted, so I will disable deletes.

#

Note: the Status and Priority checkboxes in Preferences don't do anything.

$g_notify_flags['deleted']  = array('bugnotes'  => OFF,
                                    'monitor'   => OFF,
                                    'handler'   => OFF,
                                    'reporter'  => OFF);    

This override causes updaters (aka beta testers) to receive notifications of all new

bug reports and bugnotes, regardless of whether they are in one of the four notification roles.

In other words, it gives notifications for all projects. Developers still only receive notifications

for their own projects (since this is what they wanted).

$g_notify_flags['new']['threshold_min'] = UPDATER;
$g_notify_flags['new']['threshold_max'] = UPDATER;

$g_notify_flags['bugnote']['threshold_min'] = UPDATER;
$g_notify_flags['bugnote']['threshold_max'] = UPDATER;

#

Manager receives notifications using the $g_to_email address.

edited on: 04-26-04 10:07

If this is still so unclear, the documentation will have to be improved on this. I've seen a lot of people have trouble with this.

The items in the second and third paragraphs have been fixed with 0003772 (in CVS).

The documentation for email actions ($gnotify*flags) is being updated for the next release.

This leaves the control (on/off) of messages on assignment change and non-status update to be looked into.

Some cleanup is still needed. I will change the following:

1) There will be a separate entry for each status (corresponding to $g_status_enumstring, with spaces replaced by underscores). Emails will be sent on the status chenge event. "new" is a required status. The "status<state>" entries will be eliminated.

2) There will be an entry for "updated" used when the bug control information is changed (e.g, ETA, ...).

3) There will be an entry for "owner" used when the person the bug is assigned to changes. This replaces the current "assigned" which is also a status.

4) There will be a "sponsor" entry used for all sponsorship changes. This replaces the "sponsorship_added", "sponsorship_updated", and "sponsorship_deleted" entries (which are new).

5) Relationship changes will be sent using the "relation" action. In the case of a child bug being closed, the parent "handler" will also be notified.

edited on: 08-22-04 08:21

fixes implemented in CVS