View Issue Details

IDProjectCategoryView StatusLast Update
0006640mantisbtemailpublic2010-09-19 03:13
ReporterLynk Assigned Todhx  
Status closedResolutionduplicate 
Product Version1.0.0rc1 
Summary0006640: No email sent when issue assigned through change status

With an issue open click "Change Status To" and change who the issue is assigned to and in some cases no email is sent, I have had varied results when changing it from one developer to another and it particularly always seems to fail when changing from unassigned it does not email the person who has just been assigned to.



duplicate of 0010226 closeddhx No email on 'update->assign' 
related to 0006935 closedthraxisp Emails are not send on acknowledged change status 
related to 0006883 new Email notification during change status with assign 
related to 0003588 new Handler may not be emailed when a reported bug is immediately assigned 
related to 0007279 acknowledged No email assign notification when bug is immediately assigned 
related to 0006598 new Wrong email notifications are sent if a new issue is immediately assigned ! 




2006-02-16 08:29

reporter   ~0012167

In Mantis 1.0.0 stable, no email is sent to reporter when developer closes the issue by "Change Status To". When the same operation is made by "Update Issue" button, reporter gets email notification.



2006-02-16 08:53

reporter   ~0012168

I can also confirm the problem still exists in 1.0.0 stable, I've just upgraded.



2006-02-17 21:06

reporter   ~0012182

Is anyone receiving emails on close? Is the configuration set up to send emails on close (Manage -> Manage Configuration -> Email Notifications)?



2006-02-20 04:38

reporter   ~0012193

I can confirm that emails are being sent when the status is changed (including closed) but when the "Assigned To" person is changed the person it is changed to is not emailed regarding a new assignment (this is under 1.0.0 stable)



2006-02-20 07:53

reporter   ~0012195

In Manage -> Manage Configuration -> Email Notifications Send-emails-on-close box is checked.

I did some additional tests:

  • as a reporter_1 I've added new issue, which was automaticaly assigned to developer_1;
  • as a developer_1, in Viewing Issue Simple Details screen I've changed status to "in progress" and I've added a note in next screen; email notification was sent to reporter_1;
  • as a developer_1 I've sent a reminder to developer_2 and reporter_2 - email notification was sent to those people and to reporter_1;
  • as a developer_1, in Viewing Issue Simple Details screen I've changed status to "closed" and in next screen I've added a note; no email notification was sent to reporters and developers (_1 and _2)

I've also checked log of email server on my Mantis server: none email was sent at time when developer_1 have closed that issue.



2006-02-20 08:17

reporter   ~0012196

Just to be clear, for me it doesn't seem to be limited to Closing issues but any status change during which it is also assigned



2006-03-27 05:45

reporter   ~0012417

Also in my case (Issue 6883) happend for all change status



2006-04-20 09:41

reporter   ~0012642

Also with 1.0.2 the problem persist



2006-04-21 20:35

reporter   ~0012669

Can you check to see that the expected recipients have enabled receiving emails? I can't reproduce the missing emails.

There was additional email logging added to this release (1.0.0) to track this. See for details. Adding lines like the following will log the determination of recipients:

$g_log_destination = 'file:/tmp/mantis_log';


2006-04-24 08:29

reporter   ~0012697

I just changed the two following lines in config_defaults_inc.php...
$g_log_destination = 'file:/tmp/mantis_log';

Note the quotes around the $g_log_level value, these are missing on the previous post and the docs

I can't seem to get it to log to the file tho, I tried touching the file to create it and also changing the owner to the same as the webserver is running as and even "chmod 777"-ing it but all to no avail?

The exact behavior I am seeing is that when a job has it's status changed to "Feedback Required" (enum status string "20") an email IS sent. When it's changed to "Active" (enum status string "50") an email IS NOT sent.

I can confirm that the users have the setting "Email on Status Change" disabled tho they all asure me that they havn't changed those settings? Are they the defaults?

Now I have changed the settings for those users emails are sent for both changes but the behaviour isn't quite as I expected, the email was sent on a status change (before I changed their preferences), just not on "assignment"?

Is there a way of setting all the users (current and future) to default to emails being sent all the time, a status change (particularly assignment) is a rather important change so I would expect emails to be sent by default anyway.

If there's something stupid I'm doing re the logs let me know, and I'll try and get them off again for you, thanks!

P.S. I'm still on 1.0.1 ATM.



2006-04-24 14:13

reporter   ~0012700

Last edited: 2006-04-24 14:34

$g_log_level should not be quoted as it referrs to constants defined elsewhere in the program. This would explain why nothing is logged.

Also, you should add these lines to your config_inc.php file, rather than editting config_defaults_inc.php. This will allow you to return to defaults more easily.

Blocking notifications on these status changes is the default. You can enable it by adding "$g_default_email_on_status = ON;" to your config_inc.php file.



2006-06-27 13:12

reporter   ~0013040

I've seen this problem in a slightly different manner. I have two developers (Developer A & B) who are using the default settings for notifying users of status changes (e.g., off).

Let's say that Developer A reports an issue. He (or any other user for that matter) then wants to assign the issue to Developer B. I get different results depending on how A assigns the issue:

(1) If A assigns the issue on the 'View Issue' page using the 'Assign To' button, an email is sent to B letting him know that it's been assigned to him.
(2) If, on the other hand, A assigns the issue by going to 'Update Issue', the email is not sent to B.

To me, it seems like both of these should be treated the same way (i.e., the emails should either both be sent out or not sent out.) However, perusing the log files gives me this:

06-27-2006 10:29 EDT mail_recipient bug= 12, add reporter=7
06-27-2006 10:29 EDT mail_recipient bug= 12, add handler=5
06-27-2006 10:29 EDT mail_recipient bug= 12, add note=1
06-27-2006 10:29 EDT mail_recipient bug= 12, drop 1 (own)
06-27-2006 10:29 EDT mail bug=12, type=owner, msg=email_notification_title_for_action_bug_assigned, recipients=(...)

06-27-2006 10:37 EDT mail_recipient bug= 12, add reporter=7
06-27-2006 10:37 EDT mail_recipient bug= 12, add handler=5
06-27-2006 10:37 EDT mail_recipient bug= 12, add note=1
06-27-2006 10:37 EDT mail_recipient bug= 12, drop 5 (pref email_on_status off)
06-27-2006 10:37 EDT mail_recipient bug= 12, drop 1 (own)
06-27-2006 10:37 EDT mail bug=12, type=assigned, msg=email_notification_title_for_status_bug_assigned, recipients=(...)

I do notice that the msg names are different, but to me that shouldn't make a difference, since we're performing the same operation.

BTW, I'm using Mantis 1.0.1.



2006-07-05 23:04

reporter   ~0013071

From the logs, user 0000005 (handler) has their "Message on status change" flag turned off.

The difference in handling is related to the method of update. Using the "Assign to" button is treated as purely a change in owner, while using the "Update" page treats it as a change of status.

This should probably be made more consistent if possible.



2006-07-28 16:38

reporter   ~0013162

To fix the problem as far as my users are concerned, I went into core/bug_api.php to the bug_update function. By default (at least in my version - 1.0.1), it checks status changes, then assignee changes. I swapped the order of these so that it would check the assignee change first. This seems to have solved my problem, since, by default, "Email on Change of Handler" is turned on.

However, if people have changed their settings so that "Email on Change of Handler" is turned off, then this would cause them to stop receiving emails.

The big issue here is that assigning a new bug to someone from the 'Update Issue' page (or, indeed, any way) causes two different changes (to the status and to the assignee). Thus, it seems to me that the best way to fix this is to send out emails to everyone elgible (based on the notes / handler / etc.) who has at least one of the "Email on <option>" that apply to the overall change.



2008-09-18 06:05

reporter   ~0019409

Still an issue in version 1.1.2.

If I assign an issue to a developer at status change, he doesn't get any notification about that if he had switched off notifications about status changes.

Issue History

Date Modified Username Field Change
2006-01-26 19:53 Lynk New Issue
2006-02-16 08:29 Moloch Note Added: 0012167
2006-02-16 08:53 Lynk Note Added: 0012168
2006-02-17 21:06 thraxisp Note Added: 0012182
2006-02-20 04:38 Lynk Note Added: 0012193
2006-02-20 07:53 Moloch Note Added: 0012195
2006-02-20 08:17 Lynk Note Added: 0012196
2006-03-27 05:45 dapozzom Note Added: 0012417
2006-04-20 09:41 dapozzom Note Added: 0012642
2006-04-21 20:24 thraxisp Relationship added related to 0006935
2006-04-21 20:35 thraxisp Note Added: 0012669
2006-04-24 08:29 Lynk Note Added: 0012697
2006-04-24 14:13 thraxisp Note Added: 0012700
2006-04-24 14:34 thraxisp Note Edited: 0012700
2006-06-27 13:12 radams Note Added: 0013040
2006-07-05 23:04 thraxisp Note Added: 0013071
2006-07-05 23:04 thraxisp Status new => confirmed
2006-07-26 08:58 ryandesign Relationship added related to 0007279
2006-07-26 08:59 ryandesign Additional Information Updated
2006-07-26 09:01 ryandesign Relationship added related to 0006883
2006-07-26 09:06 ryandesign Relationship added related to 0003588
2006-07-26 09:07 ryandesign Relationship added related to 0006598
2006-07-28 16:38 radams Note Added: 0013162
2008-09-18 06:05 bzz Note Added: 0019409
2008-10-20 04:59 jeongeon Tag Attached: manage_config_email
2010-06-19 01:21 dhx Relationship added duplicate of 0010226
2010-06-19 01:21 dhx Status confirmed => resolved
2010-06-19 01:21 dhx Resolution open => duplicate
2010-06-19 01:21 dhx Assigned To => dhx
2010-09-19 03:13 dhx Status resolved => closed