Centralised Notifications core consists of the following parts:
|The notifiable event resolver abstract class is designed to be extended by Totara notification resolver classes to provide information such as notification name, applicable scheduling rules, available recipient types, and other static properties required by Centralised Notifications core processing. Each notifiable event interface needs a corresponding notifiable event resolver. This class manages the data relating to an event that has occurred. It's main purpose is to transform the raw data of the event and answer questions such as "when did the event occur" and "who are the recipient users in relation to this event". Classes extending this class are considered as event parts for which either embedded or custom notifications can be made. This classes must be placed in component's totara_notification\resolver namespace to allow auto-discovery (e.g. namespace your_component\totara_notification\resolver)namespace your_component\totara_notification\resolver).|
These three interfaces can be added to a notifiable event resolver (in any combination) to add additional functionality.
See the documentation inside these interfaces for more details about how they work, when they should be used, and how to use them.
|Helper method to use for notifications triggering. It should be called whenever notifications should be sent. Typically it will be various event observers since notifiable_event_observer constructor requires event data to work.|
|The notifiable events queue stores the information about a notifiable event that needs to be processed into notifications. This is done for performance reasons, since processing events can take a lot of time, so when an event is triggered, it doesn't do much, it just puts the information into a queue. This is entity class for the 'notifiable_event_queue' table.|
|The notification abstract class is used to define built-in notifications which are wired to notifiable events. A notification subclass implements all the default properties of a notification which should be sent when the event occurs. Built-in notifications can be modified, by "overriding" one or more of the default properties, by an administrator through the interface.|
|The notifications queue stores information about notifications that were produced during processing of the event queue. Each record in the queue represents one notification which should be sent to some set of recipients, through the configured output channels, at the scheduled time.|
|The process events queue scheduled task takes records from the notifiable events queue and prepares notification records (one event can lead to several notifications). However, it doesn't send those notifications (this is done by process notifications queue scheduled task).|
|The process notifications queue scheduled task takes records to be sent and actually sends them to the chosen recipients, taking into account their settings, admin settings, notification outputs, etc.|
|\totara_notification\task\process_scheduled_event_task||The process scheduled event scheduled task process all notifications with enabled schedulers. For each notification scheduled on future or past time, it calculates if this notification has any related event that should trigger this notification within timeframe between last run of this task and now, and adds them into notification queue.|
Notifiable events are generally attached to the Totara event subsystem, so to create a new notifiable event you need to implement an event and trigger it in the required place.
Refer to the Notification events documentation on how to create and trigger events. When processing event in the observer, use \totara_notification\external_helper::create_notifiable_event_queue() to trigger notifications:
|ancestor_id||INT||NULL||This column is to keep track of the original notification (either built-in or custom) which is being overridden. If the value of this column is null, then it is saying that the notification preference record is a custom one at context/identifier.|
The notifiable event resolver class name, which this notification_preference had been created for.
The built-in notification class name. The value of this collumn column can help the notification_preference fallback to whatever the value for body, subject, body_format and so on had been defined by developer in code.
When the record is a custom notification preference, then this field MUST be NULL.
|context_id||INT||NOT NULL||The context's id which the notification preference is for.|
|component||VARCHAR||NULL||Part of extended context.|
|area||VARCHAR||NULL||Part of extended context.|
|item_id||INT||NOT NULL||Part of extended context.|
|title||VARCHAR||NULL||The notification preference's title. This field only has to be filled when the user first create a new custom notification. Otherwise it MUST always be null and MUST NOT be updated for overridden record.|
|recipient||VARCHAR||NULL||The recipient's name of notification preference record.|
|subject||VARCHAR||NULL||The subject of notification. If this is a custom notification then it is required, otherwise null to fallback to the default defined in ancestor notification.|
|subject_format||INT||NULL||The text format for subject of notification. If this is a custom notification then it is required, otherwise null to fallback to the default defined in ancestor notification.|
|body||VARCHAR||NULL||The body of notification. If this is a custom notification then it is required, otherwise null to fallback to the default defined in ancestor notification.|
The text format for body of notification. If this is a custom notification then it is required, otherwise null to fallback to the default defined in ancestor notification.
|time_created||INT||NOT NULL||Timestamp of when record was created.|
|schedule_offset||INT||NULL||When notification should be sent in relation to event time in seconds.|
|enabled||INT||NULL||Enable/Disable sending notification.|
|forced_delivery_channels||VARCHAR||NULL||what channels should be sent regardless of user preferences.|