On this page

All pages






Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space TDDM and version 1

...

Centralised Notifications core consists of the following parts:

PartDescription

\totara_notification\resolver\notifiable_event_resolver

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).

totara_notification\resolver\abstraction\additional_criteria_resolver
totara_notification\resolver\abstraction\permission_resolver
totara_notification\resolver\abstraction\scheduled_event_resolver

These three interfaces can be added to a notifiable event resolver (in any combination) to add additional functionality.

  • When configuring a notification, a resolver which implements the additional_criteria_resolver interface can add form fields allowing notification admins to configure criteria which must be met before the notification will be sent.
  • If a plugin has capabilities which specifically grant capability to configure notifications of that type, then they should be specified by implementing the permission_resolver interface.
  • Notifications that can be sent either before or after the event occurred need to implement the scheduled_event_resolver. The resolver will then be required to implement a function which retrieves all events which occurred between two given points in time.

See the documentation inside these interfaces for more details about how they work, when they should be used, and how to use them.

\totara_notification\external_helper::create_notifiable_event_queue()

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.

\totara_notification\entity\notifiable_event_queue

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.

\totara_notification\notification\built_in_notification

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.

\totara_notification\entity\notification_queue

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.

\totara_notification\task\process_event_queue_task

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).

\totara_notification\task\process_notification_queue_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_taskThe 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:

...

Column NameTypeNullableDescription
idINTNOT NULL
ancestor_idINTNULLThis 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.
resolver_class_nameVARCHARNOT NULL

The notifiable event resolver class name, which this notification_preference had been created for.

notification_class_nameVARCHARNULL

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_idINTNOT NULLThe context's id which the notification preference is for.
componentVARCHARNULLPart of extended context.
areaVARCHARNULLPart of extended context.
item_idINTNOT NULLPart of extended context.
titleVARCHARNULLThe 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.
recipientVARCHARNULLThe recipient's name of notification preference record. 
subjectVARCHARNULLThe 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_formatINTNULLThe 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.
bodyVARCHARNULLThe body of notification. If this is a custom notification then it is required, otherwise null to fallback to the default defined in ancestor notification.
body_formatINTNULL

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_createdINTNOT NULLTimestamp of when record was created.
schedule_offsetINTNULLWhen notification should be sent in relation to event time in seconds.
enabledINTNULLEnable/Disable sending notification.
forced_delivery_channelsVARCHARNULLwhat channels should be sent regardless of user preferences.

...