View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0019459||mantisbt||public||2015-03-02 11:01||2015-11-28 04:00|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||1.3.0-beta.2||Fixed in Version||1.3.0-beta.2|
|Summary||0019459: Support disable all issue notifications via user preferences|
If a user goes into their user preferences and unchecks all notification types, they still get notifications for some change types that are not supported in the preferences. These include:
|related to||0013178||confirmed||Unable to turn off email notifications for custom field changes|
|related to||0011703||confirmed||Email notification for issue updates can not be managed by Manage Configuration - E-mail Notification|
|related to||0012030||confirmed||Email notify flags do not always work|
|related to||0020323||new||Update schema to support user preferences for more email events|
The above PR is a temporary fix which enables users to disable all issue related notifications, which they can't do today. Users have been complaining that unticking all email notifications in preferences still sends them emails.
The standard fix involves:
Instead of adding columns, I would rather change the schema to have a json for preferences or a row per preference rather than having to change the schema every time we want to add a preference.
We may also want to enable plugins to have the concept of user settings. This work is beyond the scope of the fix, but if we are going to go there, then let's do it right than adding and then removing the extra fields.
If we end up revisiting preferences, then we should also look at the user_print_pref table.
MantisBT: master 02989615
2015-03-07 23:47:39Details Diff
|Temp fix to inability to disable notifications
The proper fix for this is not trivial involving database schema change, localization, etc.
Until this is done, we will treat uncustomizable notifications the same way as the
default preference where the "email_on_status" preference is used.
The issue will not be marked as resolved until we add the necessary preferences.
However, we should consider a model where adding user preferences doesn't
require a schema change.
|mod - core/email_api.php||Diff File|
|2015-03-02 11:01||vboctor||New Issue|
|2015-03-02 11:22||rombert||Relationship added||related to 0013178|
|2015-03-07 23:52||vboctor||Assigned To||=> vboctor|
|2015-03-07 23:52||vboctor||Status||new => assigned|
|2015-03-07 23:52||vboctor||Note Added: 0049151|
|2015-03-07 23:54||vboctor||Relationship added||related to 0011703|
|2015-03-07 23:54||vboctor||Relationship added||related to 0012030|
|2015-03-07 23:55||vboctor||Description Updated||View Revisions|
|2015-03-10 10:38||vboctor||Changeset attached||=> MantisBT master 02989615|
|2015-03-10 10:54||vboctor||Status||assigned => resolved|
|2015-03-10 10:54||vboctor||Resolution||open => fixed|
|2015-03-10 10:54||vboctor||Fixed in Version||=> 1.3.0-beta.2|
|2015-03-10 10:54||vboctor||Target Version||=> 1.3.0-beta.2|
|2015-03-15 19:58||dregad||Status||resolved => closed|
|2015-04-28 03:37||vboctor||Tag Attached: mantishub|
|2015-11-28 04:00||vboctor||Relationship added||related to 0020323|