View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0020371||mantisbt||public||2015-12-09 22:11||2016-06-12 00:42|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||1.3.0-rc.2||Fixed in Version||1.3.0-rc.2|
|Summary||0020371: Email notifications are not sent to explicit users when notify flags are overridden in DB|
As part of 0019731, I've started using the "explicit" recipient feature to trigger notifications for previous handler when an issue is unassigned or re-assigned. This works fine when email notifications are not overridden in DB, since the 'explicit' notify flags is ON by default.
In an instance where the administrator has overridden the flags via our web UI, the persistent config will have explicit not set for default_notify_flags which will cause such explicit recipients to not be included.
Here are three things that we should fix:
I don't see us using this feature except with the new usage I introduced in 1.3.0-rc.1. I wonder if we should have explicit notifications always ON.
Reminder sent to: atrol, dregad
Do you have thoughts on this?
I can't think of a use case for having explicit = OFF, but apparently someone did judging by your bug report.
In other words, might be worth checking with them what the reason is, and what would be the impact if the option was removed. Personally I don't have a strong opinion either way.
Maybe looking at the history when "explicit" has been introduced (commit 514ba802 to fix 0005896) helps to get a better impression.
Let's start with fixing the bug, then we can decide whether to remove this flag as a separate issue.
The end user never sees the "explicit" flag in the config UI. So after altering the flags they see, the web UI stamps default_notify_flags and notify_flags, but none of them has an "explicit" flag, hence, the code decides that this flag must be disabled. Though the user didn't even know it existed or turn it OFF.
The fix is to check notify flags via config_get if set, then default notify flags via config_get if set, then check default_notify_flags using config_get_global().
Hence, the user can still control the explicit flag, but only via the config_inc.php until we remove this flag or add it to the UI.
MantisBT: master 9a02d241
2015-12-10 23:36:31Details Diff
|Use global default_notify if flag not in DB config
The web UI currently doesn't support the explicit notify flag,
hence, when default_notify_flag and notify_flag are saved based
on administrator using web UI to override configs, such settings
will not include the 'explicit' flag causing it to be considered
false. The fix is to fallback to the global config when overridden
configs in db for notify_flags and default_notify_flags don't have
the requested flag.
|mod - core/email_api.php||Diff File|
|2015-12-09 22:11||vboctor||New Issue|
|2015-12-09 22:11||vboctor||Status||new => assigned|
|2015-12-09 22:11||vboctor||Assigned To||=> vboctor|
|2015-12-09 22:11||vboctor||Tag Attached: mantishub|
|2015-12-09 22:11||vboctor||Note Added: 0052088|
|2015-12-10 02:41||vboctor||Description Updated||View Revisions|
|2015-12-10 05:24||dregad||Note Added: 0052089|
|2015-12-10 06:25||atrol||Note Added: 0052090|
|2015-12-10 23:43||vboctor||Note Added: 0052100|
|2015-12-11 19:49||vboctoradmin||Changeset attached||=> MantisBT master 9a02d241|
|2015-12-11 19:49||vboctoradmin||Assigned To||vboctor => vboctoradmin|
|2015-12-11 19:49||vboctoradmin||Status||assigned => resolved|
|2015-12-11 19:49||vboctoradmin||Resolution||open => fixed|
|2015-12-11 19:49||vboctoradmin||Fixed in Version||=> 1.3.0-rc.2|
|2015-12-11 20:16||vboctor||Assigned To||vboctoradmin => vboctor|
|2016-06-12 00:42||vboctor||Status||resolved => closed|