Deleting user email address that is set for group notification breaks notifications for group and its subgroups.
Summary
Deleting a user secondary email address that is specified as a group notification email does not update notification settings
, leaving the group referencing an invalid notification email address, and preventing notifications from being sent for the group, and for any sub-groups that are set to use "Global notification email".
Furthermore, the notification drop-down for the group disappears from the notifications UI, preventing the user from changing the email address to a valid value.
Steps to reproduce
User user1 has two email addresses:
- primary email: user1@gitlab.example.com
- secondary email: user1-sec@gitlab.example.com
User1 is a member of group10. Group10 has a sub-group group10-subgroup1.
User1 notification settings are initially set as:
- Global notification email: user1@gitlab.example.com
- Group10 notification email: user1-sec@gitlab.example.com
- Group10-subgroup1 notification email:
Global notification email
Notifications are sent as expected to user1-sec@gitlab.example.com for events relating to group10 and group10-subgroup1 (sub-groups inherit the settings from parent groups, despite the confusingly-labelled Global notification email
option, which really means "inherit from parent group custom settings or global settings").
User1 then deletes secondary email user1-sec@gitlab.example.com from their profile.
In the database the notification_settings
table is not changed and continues to store what is now an invalid notification_email
address of user1-sec@gitlab.example.com against group10.
The notifications UI now doesn't show any email selection drop-down against group10, so the invalid email address can't be changed from there. Fixed in !128296 (merged). Nor can it be changed via the API (refer #273793).
Notifications continue to be attempted to be sent to the invalid email address for the group and its subgroup.
The subgroup settings can be overridden to use the valid email address.
Example Project
No example provided at this time.
What is the current bug behavior?
Invalid email address remains in notification_settings
and continues to be used.
What is the expected correct behavior?
Any notification_settings
records referencing the deleted secondary email address should be updated at the time the address is deleted to have null notification_email
addresses.
Relevant logs and/or screenshots
Output of checks
This bug happens on GitLab.com
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true
)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
)(we will only investigate if the tests are passing)