Notifications

Details about our notification sub-system.

This sub-system is based on the Event::Base, EventSubscription and Notification classes.

An Event describes things that happen throughout the whole OBS (backend+frontend). For instance:

• A comment is added to a package
• Someone sent a submit request for a package

A Subscription is specific for a User, a Group, a type of Event (eventtype=Event::CommentForPackage), a Role the User might have (receiver_role="maintainer") and the place where it should be displayed (channel=web, channel=instant_email)

See the Events page for deeper information about Event & Subscription.

A Notification is for a specific Event, a User (subscriber_id=1) and one or more places where it should be displayed (rss=true, web=false). There are mainly three types of notifications in OBS (Email, Web, and RSS).

Triggering a Notification

For Subscribers

All notifications are triggered with the help of SendEventEmailsJob. This job depends on:

• NotificationService for Web and RSS feeds
• EventMailer for emails

NotificationService::Notifier takes the event object and notify the subscribers for Web and RSS feeds.

System Wide Notifications

Admins on OBS can generate system wide notifications under configurations menu. For system wide notifications OBS needs an EventSubscription with empty user_id and group_id.

Workflow

• An Event gets stored in the database
• clockwork periodically schedules a SendEventEmailsJob every 30 seconds.
• SendEventEmailsJob goes over the Event table and
  • sends e-mail for all Event that have email subscribers
  • creates Notification for all Event that have web/rss subscribers

Avoiding Duplicate Notifications

OBS use mails_sent column in events table to keep track of the events that are notified, regardless of the channel (Web/RSS/Email). Once an event is notified mails_sent is set to true.

What Is Notified And What Is Not

There are many Events happening in OBS all the time. Some of them can end up in Notifications to the users interested in those events. A user can configure what kind of notifications they want to receive (email, web notification, RSS) and about what (new request in one of the user's packages, the user is asked to review something, someone wrote a comment on user's project, etc.)

Notifications for Web and RSS

These events generate notifications for Web and RSS.

• Event::ReviewWanted
• Event::RequestCreate
• Event::RequestStatechange
• Event::CommentForProject
• Event::CommentForPackage
• Event::CommentForRequest

Notifications for Email

In addition to the events mentioned above, email notifications use two addtional events.

• Event::BuildFail
• Event::ServiceFail

The user will receive a Notification when:

• someone else originates the action onto a request/project/package in which the user is involved. For example, if someone writes a comment or sent a request to a package of the user and the user is maintainer of that package,
• someone asks the user to review a request, even if the user was not previously involved in the package,
• someone mentions user's name in a comment, even if the user was not previously involved in the request/project/package,
• the request, in which the user is involved, changes its state to some of the so-called "final states": accepted, declined, superseded, revoked.

Notifications for Incoming Requests

The filter Incoming Requests displays every notification in which the associated request was created by someone else towards a package where the user is involved.

Notifications for Outgoing Requests

The filter Outgoing Requests displays every notification in which the associated request was created by the user itself.

Notifications for Comments

The filter Comments displays the notifications that are generated when someone comments on a Project/Package and the user is involved in that Project/Package.

Notifications for Requests

The filter Requests displays the notifications that are generated when a request changes it's state.