-
Notifications
You must be signed in to change notification settings - Fork 461
Notifications
Details about our notification sub-system.
- An
Eventgets stored in the database -
clockworkperiodically schedules aSendEventEmailsJobevery 30 seconds. -
SendEventEmailsJobgoes over theEventtable and-
EventMailersends email aboutEventthat have a emailEventSubscription -
NotificationService::NotifiercreatesNotificationfor allEventthat have web/rssEventSubscription - Once done
Event.mails_sentis set totrueso the event subsystem knows we are done and can clean up after itself.
-
An Event describes things that happen throughout the whole OBS. See the Events documentation for details.
People subscribe to an event by creating an instance of EventSubscription in the database.
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)
The code below will, for instance, create an email subscription for the user henne for all Event::BuildFail events, concerning packages henne is maintainer of.
EventSubscription.create(eventtype: "Event::BuildFail",
receiver_role: "maintainer",
user: User.find_by(login: 'henne'),
channel: "instant_email",
enabled: true)All EventSubscription instances that have neither the user nor the group attribute set are considered for all users and groups.
Those defaults can only be created by OBS admins via the UI. In a fresh OBS installation there are no instances of EventSubscription.
EventSubscription does not have a direct association with events. OBS uses EventSubscription::FindForEvent to find people who have subscribed to an event.
EventSubscription::FindForEvent.new(@event).subscriptions(:instant_email)The process looks like that:
- For each
Role(e.g.commenter,maintaineretc.), find all the people that possibly would get a notification - Filter out the people that don't have a subscription for this type of
Event,Roleand "channel"- Also consider the default app wide default subscriptions
- Skip the event originator because we consider this too much noise
- Return all subscribers
SendEventEmailsJob then uses those subscriptions to decide whom to notify.
A Notification collects information about
- an
Event - that happened to a thing (
BsRequest,Commentetc.) in OBS (notifiableassociation) - other things in OBS (
ProjectorGroup) involved with the notifiable (notified_projects,groupassociations) - a channel to display the notification on (
rss=true,web=falseattributes) - people (
UserorGroup) to display them to (subscriberassociation)
The code below will, for instance, create a web notification for the user henne, concerning henne home project.
Notification.create(title: 'A comment was made for home:henne',
event_type: 'Event::CommentForProject',
event_payload: {pay: :load},
subscriber: User.find_by(login: 'henne'),
subscription_receiver_role: 'maintainer',
notifiable: Project.find_by(name: 'home:henne'),
web: trueAll notifications are created with the help of SendEventEmailsJob (yes this is a bad name and should change 😞). This job is using classes in the NotificationService module to create Notification. Depending on the subscription channel a bit different.
NotificationService::WebChannel.new(@event, @subscription).call- As we only display the latest state of thing the notification is about we find the existing notifications for the notifiable and delete them
- Create/Update the
Notificationand it's associations
NotificationService::RSSChannel.new(@event, @subscription).call- Create the
Notificationand it's associations if it does not exist
The UI/API then uses the rich data the Notification collected to display/filter what's going on in OBS for people on /my/notifications
If you somehow need to process any pending notifications, execute SendEventEmailsJob.new.perform_now in a Rails console. This is especially useful when testing changes in the notifications feature after you've generated a few events like writing a comment in a request or adding a reviewer to a request.
When working on the notifications feature, it's helpful to have a few notifications for the My Notifications page. You can generate them by executing the following commands in your Docker development environment:
-
bundle exec rake dev:development_testdata:create(This will reset your development database and setup the Admin user) -
bundle exec rake dev:notifications:data[2](This will create notifications for the Admin user)
- Development Environment Overview
- Development Environment Tips & Tricks
- Spec-Tips
- Code Style
- Rubocop
- Testing with VCR
- Test in kanku
- Authentication
- Authorization
- Autocomplete
- BS Requests
- Events
- ProjectLog
- Notifications
- Feature Toggles
- Build Results
- Attrib classes
- Flags
- The BackendPackage Cache
- Maintenance classes
- Cloud uploader
- Delayed Jobs
- Staging Workflow
- StatusHistory
- OBS API
- Owner Search
- Search
- Links
- Distributions
- Repository
- Data Migrations
- Package Versions
- next_rails
- Ruby Update
- Rails Profiling
- Remote Pairing Setup Guide
- Factory Dashboard
- osc
- Setup an OBS Development Environment on macOS
- Run OpenQA smoketest locally
- Responsive Guidelines
- Importing database dumps
- Problem Statement & Solution
- Kickoff New Stuff
- New Swagger API doc
- Documentation and Communication
- GitHub Actions
- Brakeman
- How to Introduce Software Design Patterns
- Query Objects
- Services
- View Components
- RFC: Core Components
- RFC: Decorator Pattern
- RFC: Backend models
- RFC: Hotwire Turbo Frames Pattern