MantisBT notifications won't email but reset password does

[csharon]

Hello, i installed MantisBT 2.5.1. I'm using SMTP server, IIS, php, and office 365 connector for sending email. Resetting passwords works without flaw and the test under utilities works fine. But mantisBT will not email notifications for whatever reason.

Here is the config code:

$g_debug_email;
$g_log_level = LOG_EMAIL | LOG_EMAIL_RECIPIENT;
$g_log_destination = 'file:\d:\mantis.log';

$g_phpMailer_method = PHPMAILER_METHOD_SMTP;
$g_smtp_host = 'TestEnvironment';
$g_enable_email_notification = ON;
$g_email_notifications_verbose = ON;
$g_administrator_email = 'name@.com';
$g_webmaster_email = name@.com';
$g_from_email = 'name@.com';
$g_return_path_email = 'name@.com';
$g_from_name = 'MantisBT Bug Tracker';

$g_notify_flags['new']['threshold_min'] = ADMINISTRATOR;
$g_notify_flags['new']['threshold_max'] = ADMINISTRATOR;
$g_default_notify_flags['bugnotes'] = On;

I read through the email guide to no avail. I also checked mysql for any hung emails in the table, which i did not find any. But i may be not typing the right command to see them.

I used "describe mantis_email_table;" and "select * from mantis_email_table" which there is nothing other than the standard data in there. Anyone have any clues?

Thanks,

[csharon]

To add on notes it is. Windows 2008 R2, iis 6.0 / 7.5, and php 5.6. I checked the logs for php only to find an undeclared identifier i solved out as well as checking the system logs. Is there anywhere else to check for the notifications being hung, if anyone knows.

[csharon]

Ok so i found the issue which is a bug. While test email and password resets go out, even with users having the proper priveleges, the email is returning access dropped.
21-Jul-2017 22:12:40 America/Chicago] 2017-07-21 22:12 CDT RECIPIENT email_api.php:280 email_collect_recipients() Issue = #43, add @U5 (reporter)

[21-Jul-2017 22:12:40 America/Chicago] 2017-07-21 22:12 CDT RECIPIENT email_api.php:290 email_collect_recipients() Issue = #43, add @U5 (handler)

[21-Jul-2017 22:12:40 America/Chicago] 2017-07-21 22:12 CDT RECIPIENT email_api.php:323 email_collect_recipients() Issue = #43, add Category Owner = @U1

[21-Jul-2017 22:12:40 America/Chicago] 2017-07-21 22:12 CDT RECIPIENT email_api.php:359 email_collect_recipients() Issue = #43, add @U1 (based on access level)

[21-Jul-2017 22:12:40 America/Chicago] 2017-07-21 22:12 CDT RECIPIENT email_api.php:427 email_collect_recipients() Issue = #43, drop @U5 (own action)

This is occuring when the user is a manager / admin / other and has access to the projects, global access, and anything available in preferences set to any ect.... Is there a way to correct the mail.api to stop reading the Access level incorrectly with a quick fix? I'm assuming this is the code in the email_api:

* Filter recipients to remove ones that don't have access to the specified bug.
*
* @param integer $p_bug_id The bug id
* @param array $p_recipients The recipients array (key: id, value: email)
* @return array The filtered list of recipients in same format
* @access private
*/
function email_filter_recipients_for_bug( $p_bug_id, array $p_recipients ) {
$t_view_bug_threshold = config_get( 'view_bug_threshold' );

$t_authorized_recipients = array();

foreach( $p_recipients as $t_recipient_id => $t_recipient_email ) {
if( access_has_bug_level( $t_view_bug_threshold, $p_bug_id, $t_recipient_id ) ) {
$t_authorized_recipients[$t_recipient_id] = $t_recipient_email;
}
}

return $t_authorized_recipients;
}


Thanks,

[csharon]

This was corrected by changing the following code in email_api.php as a quick fix:

# Check whether users should receive the emails
# and put email address to $t_recipients[user_id]
foreach( $t_recipients as $t_id => $t_ignore ) {
# Possibly eliminate the current user
if( ( auth_get_current_user_id() == $t_id ) && ( ON == config_get( 'email_receive_own' ) ) ) {
log_event( LOG_EMAIL_RECIPIENT, 'Issue = #%d, drop @U%d (own action)', $p_bug_id, $t_id );

[atrol]

I am quite sure this is not a bug but works as designed.

https://www.mantisbt.org/docs/master/en ... nfig.email

Code: Select all

$g_email_receive_own
This defines whether users should receive emails for their own actions. This option is defaulted to OFF, hence, users do not receive email notification for their own actions. 

This is the default behavior out of the box.
If you don't like it this way, there is nothing more to do than to add the following to file config_inc.php

Code: Select all

$g_email_receive_own = ON;

[csharon]

It actually wouldn't email any categories until this was set being own other or watching the bug regardless of preferences and position.