View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003588 | mantisbt | public | 2004-02-20 07:33 | 2012-11-28 05:22 | |
| Reporter | morganparry | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Summary | 0003588: Handler may not be emailed when a reported bug is immediately assigned | ||||
| Description | If users have "email on new" turned off - and in our case, everyone does - then when a bug is assigned in the initial bug report, no email is sent to the handler. This is obviously because of the check around line 248 of email_api.php (in v0.18.1.) | ||||
| Additional Information | I fixed this locally by adding the following inbetween the two lines of code in the standard email_new_bug() function: | ||||
| Tags | patch | ||||
| related to | 0006883 | new | Email notification during change status with assign | |
| related to | 0007279 | acknowledged | No email assign notification when bug is immediately assigned | |
| related to | 0006640 | closed | dhx | No email sent when issue assigned through change status |
| related to | 0006598 | new | Wrong email notifications are sent if a new issue is immediately assigned ! |
|
Easier fix for v0.18.2:
|
|
|
Under 1.0.5, my email_new_bug() modification just looks like this: function email_new_bug( $p_bug_id ) {
This ensures handlers get emailed even if they have email_on_new turned off (but email_on_assigned turned on). It's possible this could end up generating more emails than you ideally want - the extent of this depending on your particular setup - but at least notifications are always sent. I think for typical setups that someone will only receive a redundant email when a bug is reported and immediately assigned to them in a project where they receive notifications for new bugs. That's the case for us anyway. |
|
|
@morganparry: Thanks for this fix. We had the same problem here (no new notifications => no notification at all). The drawback of getting more than one email is a general problem. In this case the best way would be to suppress the first email if the second one is for the same sender. This is a general mantis issue (but normally this is handled by just calling email_generic once per script). Idea for better handling (in theory): Collect all messages during script processing and have a now_send_collected_emails function at the end of the script. The collect functions should sort the incoming messages by recipient, then by bug_id. For each bug_id the reasons (example "entered as new bug" + "assigned") could be combined (just collect them into one multi-line-string / array): "This issue is new. ====================== This of course would be a major change but could solve all those double-email-things. Each script run would always result in at most one mail per recipient and bug. |
|
|
This might be linked to 0014396. This also applies to the other issues already linked to this issue (0003588). |
|