Performance activity notifications
Notifications are configured on a per activity basis by the activity manager. Configuration is available to control the following:
- Whether a specific notification type is enabled or disabled
- The specific relationships who will be recipients of the notification
- In some cases, additional timing information stating when before/after a trigger the notification is sent
String customisation is achieved via language string customisations. Each notification-type + recipient-relationship has a separate string so different customisations can be made for different relationship types for each type of notification. By default most notification strings for a given notification type are the same for each non-subject recipient.
Notifications do not make use of the relationship resolvers. They are tied to the participant instances associated with a specific subject instance, so if a relationship changes after the creation of the subject instance, the notification will still go to the actual participant.
Notifications support placeholders within the strings ($a->something) which will be substituted with the appropriate value on a per notification basis:
| Description | Placeholder |
|---|---|
Recipient full name | $a->recipient_fullname |
| Activity name | $a->activity_name |
| Activity type | $a->activity_type |
| Subject full name | $a->subject_fullname |
| Participant full name | $a->participant_fullname |
| Relationship name (participant's relationship to subject) | $a->participant_relationship |
| Due date | $a->instance_duedate |
| Creation date | $a->instance_created_at |
| Days since instance creation | $a->instance_days_active |
| Days until due date | $a->instance_days_remaining |
| Days since due date | $a->instance_days_overdue |
| URL for activity | $a->activity_url |
| Linked activity name | $a->activity_link |
URL for participant selection | $a->participant_selection_url |
| Participant selection link | $a->participant_selection_link |
Notifications use the current Totara notifications system and will be updated to use centralised notifications once it's available.
When multitenancy is in use, notifications behaviour doesn't change all that much, because recipients are defined based on participants which is already multitenant aware. However there is an additional check to prevent notifications being sent across tenants in case a user is moved to a different tenant after the activity is underway.