View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006640||mantisbt||public||2006-01-26 19:53||2010-09-19 03:13|
|Summary||0006640: 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||closed||dhx||No email on 'update->assign'|
|related to||0006935||closed||thraxisp||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 !|
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.
I can also confirm the problem still exists in 1.0.0 stable, I've just upgraded.
Is anyone receiving emails on close? Is the configuration set up to send emails on close (Manage -> Manage Configuration -> Email Notifications)?
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)
In Manage -> Manage Configuration -> Email Notifications Send-emails-on-close box is checked.
I did some additional tests:
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.
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
Also in my case (Issue 6883) happend for all change status
Also with 1.0.2 the problem persist
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 http://manual.mantisbt.org/manual.configuration.system.logging.php for details. Adding lines like the following will log the determination of recipients:
I just changed the two following lines in config_defaults_inc.php...
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.
$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.
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.
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:
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.
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.
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.
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.
|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|