View Issue Details

IDProjectCategoryView StatusLast Update
0020323mantisbtemailpublic2019-06-17 05:53
Reportervboctor Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version1.3.0-beta.3 
Summary0020323: Update schema to support user preferences for more email events
Description

User preferences are missing the following events for emailon*:

  • email_on_deleted
  • email_on_updated
  • email_on_sponsor
  • email_on_relation
  • email_on_monitor

The following user preference is not used:

  • email_on_priority

Currently we are mapping all of the above to email_on_status.

We can either add columns to user preference table or add a new table with a row per preference.

Tagsschema

Relationships

related to 0019459 closedvboctor Support disable all issue notifications via user preferences 
related to 0021096 closedatrol support notification user preferences at project level 
related to 0017414 new User preferences vs. config tables 
related to 0005637 confirmed Project based email notification setting 

Activities

vboctor

vboctor

2015-11-28 04:01

manager   ~0051959

Reminder sent to: atrol, dregad

What do you guys think?

cproensa

cproensa

2015-11-28 06:50

developer   ~0051960

Hello Victor

If you are committed to notifications changes, please consider adding notification for moving issues, since its a long standing request.

atrol

atrol

2015-11-28 09:22

developer   ~0051961

We should drop the existing approach and harmonize the settings with what we have for configuration (manage_config_email_page.php)
Using the existing configuration framework would also allow project specific settings for users.

Sorry, hardly any time at the moment to be more precise.
IIRC there is an existing issue where I commented before.

dregad

dregad

2015-11-28 15:45

developer   ~0051964

These new email events make sense, +1 for that (including notification for moves as suggested by cproensa)

With regards to the approach for implementation, like atrol I think it would be worth considering to move away from the specific user_pref table and add dozens of flags in there. I always found it confusing to have some user-specific settings stored in config table (eg. columns to display) while some others are in a dedicated table.

Implementing this would be a good opportunity to effect the refactoring.

BTW shouldn't this be categorized as "feature" ?

vboctor

vboctor

2016-06-12 10:49

manager   ~0053331

I'm not working on this, so I unassigned and remove target version from 1.3.x. Also changed category to 'email'.

I'm OK with modeling preferences as configurations, but I worry about these configurations crowding the Manage Configuration page with 1000s of such preferences making the real configuration hard to find. So if we do it, I think we should think about the following:

  • User preferences are filtered out by default, but administrator can include them if they they need to troubleshoot or change them.

  • Should we support for user private user preferences. For example, can we offer plugins ability to save a user's token for a 3rd party service, or do we want each of these plugins to create their own tables. I think it would be nice to provide them with a key-value storage that doesn't involve schema change and I think config table seems to be the closest to that. tokens table isn't good because it uses numeric ids for tokens rather than strings. Though that can be changed too.

cproensa

cproensa

2016-06-12 18:06

developer   ~0053338

User preferences are filtered out by default, but administrator can include them if they they need to troubleshoot or change them.

IIRC they are filtered by default, with the report page filter showing only "all users" type settings. usually this type of config relates to system wide configuration options.
Another valid point is to rephrase this label to something in the line of "no user specific" (i think internally its referred by NO_USER constant)

Should we support for user private user preferences. For example, can we offer plugins ability to save a user's token for a 3rd party service, or do we want each of these plugins to create their own tables.

This is currently supported, by config_set, and plugin_config_set, which accepts user and project specifications, and should work fine. Moreso, propbably it is already being used by 3rd party plugins.

Probably, the needed revision here is to refine the core system configurations to define which can be used as project/user specific, and which not.
But the supporting config_table is good as it is now

cproensa

cproensa

2016-06-12 18:09

developer   ~0053339

Regarding notifications options for users.
I strongly need the feature of setting them on a by-project basis (letting the user to configure different flags for each project)
Moving it to config table, would support this feature.

I will open a separate feature request, since its slightly different to this issue (adding new notification types)

cproensa

cproensa

2016-06-12 18:44

developer   ~0053344

+1 on atrol view on harmonizing both email configurations: those from manage_config_email_page and ccount_prefs_page.

@vboctor, did you have in mind a redesign of the notification system?
+1 on that too, even if its a longer term objective.