Notifications are used in TopazPort to send two types of messages.

1. A message the user (the person affected by an action)
2. A message to someone who has "subscribed" to an action.

We use notifications so we have a generalized way of doing this that also allows for editing the message that is sent (and supports string replacement).

Here are some examples:

To generate the "verify your account" email, we use a notification. We trigger a notification with the new account holder being the affected user. If an administrator wanted to, they could "subscribe" to these notifications and get an email whenever a new account was created.

The email that tells admins there is someone waiting to be approved for membership in their group will be generated when an admin is subscribed to a notification on potential new members.

When you want to send a notification, the function to use is TriggerNotification(). This takes the notification id (from kernel/notification_defs.php), the affected user id and an array of arguments. These are generally fill-in values and are different for each notification.

TriggerNotification figures out the notification class for this notification type, creates an object of that class and calls it to handle the notification. 

Currently we first send a message to the affected user and then we look for subscribers to the message and send a message to them as well. 

Finding the list of subscribers is a bit tricky because admins are allowed to subscribe to notifications on sub-sites from the parent site (just to make it easier to manage such subscriptions) and global admins can subscribe to messages across the whole install by subscribing to site #0 (which is a non-valid site number). 

Future Plans

Delayed Subscription Sending

Currently all subscriptions are sent out when the notification happens. This has the potential, if there are a large number of subscriptions, to cause the user to wait a while before the website returns. Rather than sending the email notification to subscribers immediately, we'd like to just add these subscription notifications to a queue and process them with a cron job later. This ties in well with "digests" as well.

Digest Mode

In the near future, we'd like to support a digest mode for notifications. Rather than getting notified about each new user, as one example, an admin could get a summary at the end of the day with the list of all the new users that day.

Once we have delayed notifications, we just need to wait until a particular time (or we have a particular number) to send out one email. The email template needs to be a bit different and the fill-in values will need to allow for "totals."