Notifications

Details about our notification sub-system.

This sub-system is based on the Event, Subscription and Notification classes.

An Event describes things that happen throughout the whole OBS (backend+frontend). See the Events page for deeper information about Event.

A Subscription is specific for a User, 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)

• OBS admins can create app wide defaults (EventSubscription.where(user_id: nil))
• A User can have a collection of Subscription that overwrites those defaults

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)

Workflow

• An Event gets stored in the database
• clockwork periodically schedules a SendEventEmailsJob
• 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

What Is Notified And What 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.)

Assuming the user enabled all the possible options, the user won't receive a Notification (in fact, the Event is not created) when:

• the user is who originated the action: they created a new request on someone's package or they wrote a comment,
• the request, in which the user is involved, changes its state to review and back to new because of its reviews (reviews requested or accepted)

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,
• 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.