[bug] NotificationSettings logic ignores user preferences when creating/updating settings

[pandafy]

Describe the bug
Multiple logic bugs are present in NotificationSettings where user notification preferences are ignored when settings are created or updated. Users' explicit choices (global or org-specific) are overwritten or bypassed, leading to unexpected notification behavior.

• Bug 1: New Organization Creation Ignores User's Global Preferences

  • Details:
    • When a new organization is created, notification settings for all superusers use hardcoded defaults (email=True, web=True), disregarding their globally configured preferences. The code in create_notification_settings and the ns_organization_created task uses org settings or defaults only, never inheriting from the user's global prefs.
    • Location:
      • Primary: tasks.py:83-111 (create_notification_settings())
      • Trigger: tasks.py:212-224 (ns_organization_created task)
    • Root Cause:
      • Hardcoded defaults are set (lines 84-86) via get_or_create for globals.
      • When creating org-specific settings (lines 104-111), user’s global prefs are ignored in favor of org settings.
  • Expected Behavior:
    • New org notification settings should inherit from a user's global notification preferences. If user has disabled email/web globally, org settings must respect this.

• Bug 2: Org Admin Addition Ignores Global Preferences

  • Details:
    • When adding a user as org admin, notification settings are based just on org’s settings, not on the user's global notification preferences. This is handled via update_org_user_notificationsetting which calls the flawed create_notification_settings.
    • Location:
      • Primary: tasks.py:175-198 (update_org_user_notificationsetting task)
      • Trigger: handlers.py:298-306 (organization_user_post_save signal handler)
    • Root Cause:
      • Same as Bug 1; global user preferences are omitted.
  • Expected Behavior:
    • Adding an org admin should set notification defaults based on user's global preferences.

• Bug 3: Org Settings Changes Overwrite User Preferences

  • Details:
    • When an org admin changes their organization's notification settings, all users' organization-notification settings are updated en masse without checking for explicit overrides. Thus, even user-customized settings are overwritten.
    • Location:
      • Primary: base/models.py:564-583 (AbstractOrganizationNotificationSettings._update_organizationuser_settings())
    • Root Cause:
      • The update logic applies new org settings to all NotificationSetting objects for that org without checking if users have manually customized their prefs.
  • Expected Behavior:
    • Only users who have not personally customized their org notification settings should be updated when the org's default changes.

Steps To Reproduce
Steps to reproduce each bug are summarized below:

1. Create a user with global notification settings disabling email and/or web notifications. Create a new org as superuser -> User receives enabled notices anyway.
2. Promote/add a user as org admin. Their notification type is enabled in new org regardless of their global preference.
3. As org admin, update org notification settings. All users’ org notification preferences are overwritten even if previously customized.

Expected behavior

• User’s explicit global or org-level notification preferences are never overwritten or ignored by system defaults or org changes.

[nemesifier]

@pandafy there's another case which seems buggy to me:

Email notifications disabled globally, some org settings showing email enabled, so I disabled them with:

NotificationSetting.objects.filter(email=True).update(email=False)

But they keep showing up as enabled!

It turns out they're set to None:

>>> NotificationSetting.objects.filter(email=True).count()
0
>>> NotificationSetting.objects.filter(email=None).count()
371
>>> NotificationSetting.objects.filter(email=None).update(email=False)
371

This looks very buggy, why is this happening? Emails are disabled on my user, so any email setting set to None should inherit my default, is this inheriting the default of the org instead? Is this bug number 2 in your list?