[18.0 & 19.0][base_user_role] Notification Preference reset to "email" on every change in user roles

[much-nikoklaiber]

Module

base_user_role

Describe the bug

set_groups_from_roles() silently resets every user's notification_type to 'email'
whenever a role or user record is written. The method recomputes group_ids
exclusively from role-implied groups and strips any group not covered by the
current roles — including mail.group_mail_notification_type_inbox (the group
that controls in-app vs. email notifications in the Discuss app). Since this
group is a personal preference and not typically implied by any role, it is
removed on every sync, overriding the user's individual setting without any
chatter entry or tracking value.

To Reproduce

Affected versions: 19.0, 18.0 confirmed, other versions not tested, base_user_role (OCA)

Steps to reproduce the behavior:

1. Assign at least one role to a user via Settings → Users → Roles.
2. Set that user's notification preference to "In Odoo (Inbox)" via user
   Preferences or Settings → Users → User → Preferences tab.
3. Verify the user can see Inbox and History in the Discuss sidebar.
4. Edit any field on that user role record and save.
5. Check the user's notification preference — it has silently reverted to
   "By Email", and Inbox/History have disappeared from the Discuss sidebar.

Expected behavior
set_groups_from_roles() should not touch mail.group_mail_notification_type_inbox.
This group represents a personal user preference, not a role-derived permission.
After a role sync the user's notification setting should remain unchanged,
analogous to how base.group_system is already excluded from the role diff.

Additional context

• The regression is invisible: notification_type is not tracked
  (ir.model.fields.tracking = NULL), so no chatter message or
  mail.tracking.value row is written. Affected users only notice that
  Posteingang and Historie have disappeared from the Discuss channel
  list.
• Editing a role (not just a single user) cascades via update_users() →
  set_groups_from_roles() to every user assigned to that role in a single
  write burst, making the impact wide and hard to trace.
• The ir.cron "Update user roles" (if active) reproduces the reset on its
  configured interval for all role-holding users.
• Proposed fix: exclude mail.group_mail_notification_type_inbox (or more
  generally: any group that backs a fields.Selection personal preference) from
  the add/remove diff inside set_groups_from_roles().