View Issue Details

IDProjectCategoryView StatusLast Update
0020371mantisbtemailpublic2016-06-12 00:42
ReportervboctorAssigned Tovboctor 
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version1.3.0-rc.1 
Target Version1.3.0-rc.2Fixed in Version1.3.0-rc.2 
Summary0020371: 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:

  • If explicit is OFF, then we should log the fact that there were explicit recipients that were ignored.
  • If we configure through the UI, we should make all configuration options available or at least not override the global config for missing data.
  • Do we really need an explicit flag? Or should it always be ON? For example, in case of re-assignment, I check the appropriate logical flag (ownership change notification is enabled) before adding the explicit user, rather than depending on a generic config option that doesn't mean much to the user specially that it can mean different thing for different events.

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.





2015-12-09 22:11

manager   ~0052088

Reminder sent to: atrol, dregad

Do you have thoughts on this?



2015-12-10 05:24

developer   ~0052089

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.



2015-12-10 06:25

developer   ~0052090

Personally I don't have a strong opinion either way.
Same for me and hardly any time to think more about it.

Maybe looking at the history when "explicit" has been introduced (commit 514ba802 to fix 0005896) helps to get a better impression.



2015-12-10 23:43

manager   ~0052100

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.


Related Changesets

MantisBT: master 9a02d241

2015-12-10 23:36:31


Details 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.

Fixes 0020371
mod - core/email_api.php Diff File

Issue History

Date Modified Username Field Change
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