View Issue Details

WikiRelated ChangesetsJump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0019459mantisbtemailpublic2015-03-02 11:012015-11-28 04:00
Reportervboctor Assigned Tovboctor  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version1.3.0-beta.1 
Target Version1.3.0-beta.2Fixed in Version1.3.0-beta.2 
Summary0019459: Support disable all issue notifications via user preferences
Description

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:

  • issue deleted.
  • issue updated
  • issue sponsored
  • issue relationship
  • issue monitored
  • issue priority change
Tagsmantishub

Relationships

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 

Activities

vboctor

vboctor

2015-03-07 23:52

manager   ~0049151

Pull Request:
https://github.com/mantisbt/mantisbt/pull/585

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:

  • Adding columns to user preferences table.
  • Updating UI and translating strings.
  • Changes to logic.

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.

Related Changesets

MantisBT: master 02989615

2015-03-07 18:47

vboctor


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

Issue 0019459		 Affected Issues
0019459
mod - core/email_api.php Diff File