Decouple membership and notifications
- Zendesk ticket: https://gitlab.zendesk.com/agent/tickets/11330
Iteration 1 (8.7, done)
Currently if users a only part of a group they cannot specify different notification levels for individual projects. In Enterprises where LDAP group sync is used to manage membership this becomes a larger concern.
@dzaporozhets mentions that to accomplish this we need to decouple membership and notifications. How much time does this take? Can we schedule this for an upcoming release?
Iteration 2 (8.9)
See comments on !3421 (merged), and:
Done Create migration that remove duplicates in notification_settings table and create uniq index.
add_index :notification_settings, [:user_id, :source_id, :source_type], uniq: true
In progress Move
notification_levelout of user and into
NotificationSettingmodel with a
source(!3421 (comment 4578089))
Because we don't want not-changed-from-default
NotificationSettingrecords laying around for every single user/project combination, I think we should have a method like
user.notification_settings_for(project)that will lazily return either an existing
NotificationSettingfor this project, or a newly initialized one based on the group, or on the user's global level. The
NotificationSettingwill be made concrete (saved) only when the level changes from global.
This abstraction should allow us to not bother about whether the notification settings exist in the DB at all, and do away with the
#Things to be done
- Add notification level dropdown to Group page
- Make proper API for notification settings
MemberCreateServiceinstead of Member#after_create callback for creating notification settings (after #14709)
- Check for possible UX improvements
notification_levelfield from Member model in 9.0