Filter Notifications by Group

Problem Statement & Solution Document for "Filter Notifications by Group"

Reality?

• Every time an Event happens, a user can be notified.
• What the user receives, is configured in My Subscriptions page (EventSubscription model).
• A subscription is a combination of the following actors:
  • Subscriber/receiver: User or Group
  • Channel: email, web, rss
  • Type of Event: ReviewWanted, RequestStatechange, CommentForPackage, etc.
  • Role/receiver_role: Reviewer, Maintainer, Bugowner, etc.
• Examples of subscriptions can be:
  • User1 wants to receive notifications (by web) for ReviewWanted events happening in projects where he's Reviewer.
  • User2 wants to receive notifications (by email) for RequestStatechange events happening in projects where the groups she belongs to are Mantainer.
  • User2 wants to receive notifications (by email and web) for CommentForPackage events happening in packages where she is Bugowner.
• A user can decide if he wants to be notified about events related to a group he belongs. At the moment, these notifications only work with the email channel.
• In case a user has marked a group to be notified:
  • If the group has its own email, the notification will be sent to that email.
  • If the group doesn't have any email, the notification will be sent to their members emails.

Consequences?

• It is not possible for a user to configure which groups he will receive web notifications.
• We also don't have a way to filter web notifications because the user belongs to a specific group.

Future?

• Each time a user checks a group from his list of groups in My Subscriptions, he could also be notified by web, applying the rules configured for each kind of event.

Let's say a user belongs to a group and he wants to be notified for events related to that group (checks in the group's checkbox).

• This user will receive a notification when:
  • an event of an specific type occurs,
  • the user is subscribed to receive web notifications for that event type, and some role,
  • the project or package within the event occurs, has this role defined for this group .
• Notifications of a user can be filtered by the group which user checked to be notified.

Example:

As a follow-up of one of the examples described in the Reality? section, now User2 wants to receive notifications related to her groups not only by email but also by web.

• User2 belongs to groups G1 and G2.

• Both groups are maintainers in project1.

• G1 has email, G2 has not.

• User2 wants to receive notifications (by email and web) for RequestStatechange events happening in projects where G1 and G2 are Mantainers.

• When a RequestStatechange event happens in project1:

  • An email will be sent to G1 email address because G1 has its own email.
  • An email will be sent to User2 email address because G2 doesn't have its own email.
  • A web notification will be sent to User2 because she's member of G1 and G2.

• In the notifications page for User2:

  • She will see one single notification related to the event RequestStatechange that happened in project1.
  • G1 and G2 are options in the Groups filter.
  • When User2 filters by G1 , she will see the notification in the list.
  • When User2 filters by G2, she will see the notification in the list.

Proposal!

Create a groups_notifications joining table to store the information about the groups that triggered the notification. That way, the user can filter notifications that he received because he is member of a specific group.

Right before we create a web notification, we get the groups that triggered the notification. Then, we create the notification associated to a subscriber (only User type). We always create a web notification for a final/individual user. After that, we can fill in the joining table to associate the newly created notification with all the previously extracted groups.

This solution keeps events and subscriptions as they are. We only should refactor the Notifier service.

This proposal ensures that the user will see only one notification regarding the same topic. So there won't be duplicated notifications, received as User and also as Group member.

We propose not to do data migration. The users will start to receive notifications where the groups are "mentioned" from the moment we do the deployment. Older notifications will lack the group information.