Notification handlers
A notification handler takes pending events and turns them into mail. Every handler sees every event and ignores the ones that are not its own.
The handlers of Exponential 6
- ezsubtree: What it does: for a published object, finds the users who follow the object or a node above it and may read it, and writes a message for each; Its part of the settings page: the list of followed items
- ezcollaborationnotification: What it does: mails the participants of a collaboration item, by the kinds of items each user ticked; Its part of the settings page: Collaboration notification
- ezgeneraldigest: What it does: at the digest time chosen by each user, collects the messages kept back and sends one mail; Its part of the settings page: E-mail digest
They are listed in notification.ini [NotificationEventHandlerSettings] AvailableNotificationEventTypes[] (the key keeps its old name), and their classes are in kernel/classes/notification/handler/<id>/<id>handler.php.
Writing a handler
A handler extends eZNotificationEventHandler and implements handle( $event ). To send mail it creates an eZNotificationCollection with the subject and text, adds an item per address (send date 0 for at once, a time for a digest), and passes the addresses to eZNotificationTransport::instance( 'ezmail' ). For its own block on the settings page it implements fetchHttpInput() and storeSettings() and provides notification/handler/<id>/settings/edit.tpl.
Put it in <id>/<id>handler.php below a directory listed in [NotificationEventHandlerSettings] ExtensionDirectories[] or RepositoryDirectories[], add the id to AvailableNotificationEventTypes[], and try it with a dry run: ./console exp:notificationrun --allow-root-user shows what would be sent.
A complete, tested example is in Notifications: architecture, extending and testing.
Limits
- A handler that throws an error is reported on the status page ("A handler failed on n events"); the other handlers still run, and the event is not retried.
- A message the mail transport refuses is retried at every run for [RuleSettings] RetryHours (72 hours).
Contributors
- Svitlana Shatokhina
- Geir Arne Waaler
- Graham Brookins Updated Maintainer
Comments
Add a comment