Concepts

• Every notifiable event has a list of valid schedules that are supported.
• Every notification has one schedule from the notifiable event available schedules.
• Schedule is a class that implements the totara_notification\schedule\notification_schedule interface.
• Each notifiable event holds a relative timestamp (event time), which schedules are calculated against. For example, when a session is booked, schedulers for the session reminder will be applied to session time, not booking time.

Database

Each notification has a notification_preference.schedule_offset column storing the scheduled offset in days. As we currently only support before event, on event or after event, the distinction is handled by storing the value as a negative (for before event), a positive (for after event) or 0 (for on event).

The column notifiable_event_queue.event_time stores the time of event is intended to be based off of. Each notifiable event that's triggered and set the event_time in the event data to be used. If not provided the time created is used instead.

GraphQL

Notifiable events include identifiers for the valid schedule options in the valid_schedules field, which is one of the totara_notification_schedule_type values.

enum totara_notification_schedule_type {
  ON_EVENT
  BEFORE_EVENT
  AFTER_EVENT
}

type totara_notification_notifiable_event {
# ...
  valid_schedules: [totara_notification_schedule_type!]!
# ...
}

Notification preferences will return a schedule_offset and schedule_type property, indicating the type of schedule selected and the offset involved. Plus a overridden_schedule flag, indicating this schedule was overridden from the parent, and finally a schedule_label which is a human readable label of the schedule offset and type.

The schedule_offset field is always returned as a positive number (or 0). GraphQL handles the type of schedule in play with the schedule_type parameter instead. Therefore a "3 days before event" notification preference would have a schedule_type of "BEFORE_EVENT" and a schedule offset of 3.

type totara_notification_notification_preference {
# ...
  """
  Number of days before/after/on the event the schedule should be adjusted for.
  Always a positive number, meaning is derived from the schedule_type field.
  """
  schedule_offset: Int!
  """
  The type of schedule that's in play.
  """
  schedule_type: totara_notification_schedule_type!
  """
  Whether the fields 'schedule_offset' or 'schedule_type' are overridden.
  These fields work in a pair so either both are overridden or neither are.
  """
  overridden_schedule: Boolean!
  """
  Human readable label of the active schedule_type.
  """
  schedule_label: String
# ...
}

The mutations to create, update or validate a notification preference all accept the schedule_type and schedule_offset parameters.

totara_notification_create_notification_preference {
# ...
  schedule_offset: param_integer
  schedule_type: param_text
# ...
}

totara_notification_update_notification_preference {
# ...
  schedule_offset: param_integer
  schedule_type: param_text
# ...
}

totara_notification_validate_notification_preference_input {
# ...
  schedule_offset: param_integer
  schedule_type: param_text
# ...
}

Classes/interfaces

This table outlines the classes, interfaces, and methods most relevant for scheduling notifications.