View Issue Details

IDProjectCategoryView StatusLast Update
0005061mantisbtemailpublic2005-04-18 10:32
Reporterdpardons Assigned Tothraxisp  
PrioritynormalSeverityblockReproducibilityalways
Status closedResolutionfixed 
Product Version0.19.2 
Fixed in Version1.0.0a1 
Summary0005061: e-mail recipients not removed in case of corresponding email_on_xxxaction not defined in db
Description

Function email_collect_recipients in email_api.php does not remove recipients (unset user id) in case of current action ('emailon' . $p_notify_type) not defined in database table "mantis_user_pref_table".

It seems that the else statement to process the fact that the corresponding email_on_action does not exist in table "mantis_user_pref_table" is missing.

Please refer to additional info.
Could you confirm the correction I made.
Thanks

Additional Information

Starting Line 271 of email_api.php:

Exclude users who have this notification type turned off

        if ( $t_pref_field ) {
            $t_notify = user_pref_get_pref( $t_id, $t_pref_field );
            if ( OFF == $t_notify ) {
                unset( $t_recipients[$t_id] );
                continue;
            } else {
                # Users can define the severity of an issue before they are emailed for
                # each type of notification
                $t_min_sev_pref_field = $t_pref_field . '_minimum_severity';
                $t_min_sev_notify     = user_pref_get_pref( $t_id, $t_min_sev_pref_field );
                $t_bug_severity       = bug_get_field( $p_bug_id, 'severity' );

                if ( $t_bug_severity < $t_min_sev_notify ) {
                    unset( $t_recipients[$t_id] );
                    continue;
                }
            }

START MISSING ELSE STATEMENT

        } else {
            unset( $t_recipients[$t_id] );
            continue;

END MISSING ELSE STATEMENT

        }
TagsNo tags attached.

Activities

thraxisp

thraxisp

2005-01-03 12:39

reporter   ~0008833

This looks like the email preferences needs a re-write. It is hardcoded (in the database) to match the original status values.

thraxisp

thraxisp

2005-01-04 08:08

reporter   ~0008838

The bug really lies elsewhere. On a status change, the mail routine should be called with a parameter of 'status', rather than the actual status. Missing values alre already handled by bypassing this code (i.e., $t_pref_field === false).

thraxisp

thraxisp

2005-01-05 15:54

reporter   ~0008856

With the exception of "resolved" and "closed", all status change messages are now controlled by the "email_on_status" flag. ("resolved" and "closed" have their own specific flags).

This was simpler than specific masks for all potential status values.