View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0020323 | mantisbt | public | 2015-11-28 04:00 | 2019-06-17 05:53 | |
Reporter | vboctor | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | new | Resolution | open | ||
Product Version | 1.3.0-beta.3 | ||||
Summary | 0020323: Update schema to support user preferences for more email events | ||||
Description | User preferences are missing the following events for emailon*:
The following user preference is not used:
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. | ||||
Tags | schema | ||||
related to | 0019459 | closed | vboctor | Support disable all issue notifications via user preferences |
related to | 0021096 | closed | atrol | 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 |
Reminder sent to: atrol, dregad What do you guys think? |
|
Hello Victor If you are committed to notifications changes, please consider adding notification for moving issues, since its a long standing request. |
|
We should drop the existing approach and harmonize the settings with what we have for configuration (manage_config_email_page.php) Sorry, hardly any time at the moment to be more precise. |
|
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" ? |
|
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:
|
|
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.
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. |
|
Regarding notifications options for users. I will open a separate feature request, since its slightly different to this issue (adding new notification types) |
|
+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? |
|