You have to set the class names of the database object ($objectClassName) and the related list ($objectListClassName).
Additionally, you have to create a class that implements the IUserNotificationObject whose name you have to set as the value of the $decoratorClassName property.
The getTitle() method returns the title of the object.
In this case, we assume that the Foo class has implemented the ITitledObject interface so that the decorated Foo can handle this method call itself.
The getURL() method returns the link to the object.
As for the getTitle(), we assume that the Foo class has implemented the ILinkableObject interface so that the decorated Foo can also handle this method call itself.
The getAuthorID() method returns the id of the user who created the decorated Foo object.
We assume that Foo objects have a userID property that contains this id.
Here, you reference the user notification object type created via objectType.xml.
The referenced class in the <classname> element has to implement the IUserNotificationEvent interface by extending the AbstractUserNotificationEvent class or the AbstractSharedUserNotificationEvent class if you want to pre-load additional data before processing notifications.
In AbstractSharedUserNotificationEvent::prepare(), you can, for example, tell runtime caches to prepare to load certain objects which then are loaded all at once when the objects are needed.
The $stackable property is false by default and has to be explicitly set to true if stacking of notifications should be enabled.
Stacking of notification does not create new notifications for the same event for a certain object if the related action as been triggered by different users.
For example, if something is liked by one user and then liked again by another user before the recipient of the notification has confirmed it, the existing notification will be amended to include both users who liked the content.
Stacking can thus be used to avoid cluttering the notification list of users.
The checkAccess() method makes sure that the active user still has access to the object related to the notification.
If that is not the case, the user notification system will automatically deleted the user notification based on the return value of the method.
If you have any cached values related to notifications, you should also reset these values here.
The getEmailMessage() method return data to create the instant email or the daily summary email.
For instant emails ($notificationType = 'instant'), you have to return an array like the one shown in the code above with the following components:
abbreviation of application
message id of the notification for the parent item and used to improve the ordering in threaded email clients
message id of the notification mail and has to be used in in-reply-to and references for follow up mails
all of the message ids of parent items (i.e. recursive in-reply-to)
name of the template used to render the email body, should start with email_
template variables passed to the email template where they can be accessed via $notificationContent[variables]
For daily emails ($notificationType = 'daily'), only application, template, and variables are supported.
- The getEmailTitle() returns the title of the instant email sent to the user.
By default, getEmailTitle() simply calls getTitle().
- The getEventHash() method returns a hash by which user notifications are grouped.
Here, we want to group them not by the actual Foo object but by its parent Baz object and thus overwrite the default implementation provided by AbstractUserNotificationEvent.
- The getLink() returns the link to the Foo object the notification belongs to.
- The getMessage() method and the getTitle() return the message and the title of the user notification respectively.
By checking the value of count($this->getAuthors()), we check if the notification is stacked, thus if the event has been triggered for multiple users so that different languages items are used.
If your notification event does not support stacking, this distinction is not necessary.
- The prepare() method is called for each user notification before all user notifications are rendered.
This allows to tell runtime caches to prepare to load objects later on (see Runtime Caches).
When the action related to a user notification is executed, you can use UserNotificationHandler::fireEvent() to create the notifications:
$recipientIDs=;// fill with user ids of the recipients of the notificationUserNotificationHandler::getInstance()->fireEvent('bar',// event name'com.woltlab.example.foo',// event object type namenewFooUserNotificationObject(newFoo($fooID)),// object related to the event$recipientIDs);
In some instances, you might want to manually mark user notifications as confirmed without the user manually confirming them, for example when they visit the page that is related to the user notification.
In this case, you can use UserNotificationHandler::markAsConfirmed():
$recipientIDs=;// fill with user ids of the recipients of the notification$fooIDs=;// fill with ids of related foo objectsUserNotificationHandler::getInstance()->markAsConfirmed('bar',// event name'com.woltlab.example.foo',// event object type name$recipientIDs,$fooIDs);