View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005061 | mantisbt | public | 2005-01-02 19:35 | 2005-04-18 10:32 | |
| Reporter | dpardons | Assigned To | thraxisp | ||
| Priority | normal | Severity | block | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.19.2 | ||||
| Fixed in Version | 1.0.0a1 | ||||
| Summary | 0005061: 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. | ||||
| Additional Information | Starting Line 271 of email_api.php: Exclude users who have this notification type turned off
START MISSING ELSE STATEMENT
END MISSING ELSE STATEMENT | ||||
| Tags | No tags attached. | ||||
|
This looks like the email preferences needs a re-write. It is hardcoded (in the database) to match the original status values. |
|
|
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). |
|
|
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. |
|