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?

Required for https://gitlab.com/gitlab-org/gitlab-ce/issues/9013 and https://gitlab.com/gitlab-org/gitlab-ce/issues/12758

Iteration 2 (8.9)

See comments on https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3421, 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_level out of user and into NotificationSetting model with a nil source (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3421#note_4578089)

• https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3421#note_4577930:

  Because we don't want not-changed-from-default NotificationSetting records 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 NotificationSetting for this project, or a newly initialized one based on the group, or on the user's global level. The NotificationSetting will 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 find_or_initialize_by calls.

#Things to be done

• Add notification level dropdown to Group page
• Make proper API for notification settings
• Use MemberCreateService instead of Member#after_create callback for creating notification settings (after #14709 (moved))
• Check for possible UX improvements
• Remove notification_level field from Member model in 9.0

@dzaporozhets Will you please scope this when you get time? Then we can schedule for future release.

I think we should do it anyway. So I propose 8.5 (cc @JobV ) and later I will explain what need to be done ehre

Milestone changed to 8.5

Sounds great to me. Thanks for putting in a milestone, even if it's tentative.

mentioned in issue #3778 (closed)

mentioned in issue #12758 (closed)

mentioned in merge request !2852 (closed)

Milestone changed to 8.6

@dzaporozhets You wrote "later I will explain what need to be done here". Do you want to elaborate? :)

mentioned in merge request !3047 (closed)

@DouweM I see todo like this:

• notification settings in separate model. Belongs to group or project via polymorphic
• migration to add separate notification settings object for every existing membership object
• add UI to set notification settings object even for project you are not member of (example public or you are member of group)
• cleanup membership model from notification setting

@dzaporozhets 👍

Added ~164274 label

mentioned in issue #9013 (closed)

Removed ~164274 label

Milestone changed to 8.7

Added ~122770 label

After conversation with @DouweM - I will work on some core functionality for this feature to set a direction and then pass it back to other dev for final touch.

Reassigned to @dzaporozhets

mentioned in merge request !3421 (merged)

mentioned in merge request !3180 (closed)

TODO after !3421 (merged) is merged:

• 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. Probably in 8.8
• remove notification_level field from Member model in 9.0
• make proper API for notification settings. Probably in 8.9
• use MemberCreateService instead of Member#after_create callback for creating notification settings (after #14709 (moved))
• check for possible UX improvements

@DouweM since !3421 (merged) is ready I unassign this issue. Please find someone to work on improvements.

Reassigned to @DouweM

mentioned in commit 4516f40d

@DouweM state of this? Do we have to move up https://gitlab.com/gitlab-org/gitlab-ce/issues/12758 ?

Milestone changed to 8.8

@JobV There are some next steps in this issue and https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3421 that would be nice to do for 8.8/8.9, but they don't block https://gitlab.com/gitlab-org/gitlab-ce/issues/12758. It's ~"technical debt" stuff that I'll update this issue with later.

Thanks @DouweM

Milestone changed to 8.9

Added ~168008 and removed ~14213 labels

Removed ~122770 label

Assignee removed

Reassigned to @felipe_artur

mentioned in merge request !4472 (merged)

Marked the task 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 as completed

mentioned in merge request !4494 (merged)

Marked the task https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3421#note_4577930: as completed

mentioned in commit c03f1259

Marked the task In progress Move notification_level out of user and into NotificationSetting model with a nil source (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3421#note_4578089) as completed

mentioned in merge request !4656 (merged)

mentioned in merge request !4857 (merged)

Removed ~113220 ~168008 labels

Milestone changed to %8.10

Marked the task Add notification level dropdown to Group page as completed

mentioned in commit 1d34ce13

mentioned in issue #19358 (moved)

mentioned in issue #19359 (closed)

Separated last tasks on: #19358 (moved) #19359 (closed)

Status changed to closed

Mentioned in commit jmcgeheeiv/gitlab-ce@c03f1259

Mentioned in commit jmcgeheeiv/gitlab-ce@1d34ce13

Mentioned in commit dblessing/gitlab-ce@4516f40d