19

Product support

Visit this product's website for support.

  • Added on Sep 11, 2017
  • Current version: 1.2.1
  • Platform Compatibility
    v3.x use latest
    v2.x use latest
    v1.x use latest
  • Extensions: 3
  • Created by
  • Public repository

Categories

Notification workflow

When a notification fires, it uses the following workflow:

  1. Plugin registers associated actions, conditions and events using registerNotificationRules
  2. A notification class is bound to a system event using Notifier::bindEvent
  3. A system event is fired Event::fire
  4. The parameters of the event are captured, along with any global context parameters
  5. A command is pushed on the queue to process the notification Queue::push
  6. The command finds all notification rules using the notification class and triggers them
  7. The notification conditions are checked and only proceed if met
  8. The notification actions are triggered

Here is an example of a plugin registering notification rules. The groups definition will create containers that are used to better organise events. The presets definition specifies notification rules defined by the system.

public function registerNotificationRules()
{
    return [
        'events' => [
            \RainLab\User\NotifyRules\UserActivatedEvent::class,
        ],
        'actions' => [
            \RainLab\User\NotifyRules\SaveToDatabaseAction::class,
        ],
        'conditions' => [
            \RainLab\User\NotifyRules\UserAttributeCondition::class
        ],
        'groups' => [
            'user' => [
                'label' => 'User',
                'icon' => 'icon-user'
            ],
        ],
        'presets' => '$/rainlab/user/config/notify_presets.yaml',
    ];
}

Here is an example of triggering a notification. The system event rainlab.user.activate is bound to the UserActivatedEvent class.

// Bind to a system event
\RainLab\Notify\Classes\Notifier::bindEvents([
    'rainlab.user.activate' => \RainLab\User\NotifyRules\UserActivatedEvent::class
]);

// Fire the system event
Event::fire('rainlab.user.activate', [$this]);

Here is an example of registering context parameters, which are available globally to all notifications.

\RainLab\Notify\Classes\Notifier::instance()->registerCallback(function($manager) {
    $manager->registerGlobalParams([
        'user' => Auth::getUser()
    ]);
});

Here is an example of an event preset:

# ===================================
#  Event Presets
# ===================================

welcome_email:
    name: Send welcome email to user
    event: RainLab\User\NotifyRules\UserRegisteredEvent
    items:
        - action: RainLab\Notify\NotifyRules\SendMailTemplateAction
          mail_template: rainlab.user::welcome
          send_to_mode: user

Creating Event classes

An event class is responsible for preparing the parameters passed to the conditions and actions. The static method makeParamsFromEvent will take the arguments provided by the system event and convert them in to parameters.

class UserActivatedEvent extends \RainLab\Notify\Classes\EventBase
{
    /**
     * @var array Local conditions supported by this event.
     */
    public $conditions = [
        \RainLab\User\NotifyRules\UserAttributeCondition::class
    ];

    /**
     * Returns information about this event, including name and description.
     */
    public function eventDetails()
    {
        return [
            'name'        => 'Activated',
            'description' => 'A user is activated',
            'group'       => 'user'
        ];
    }

    /**
     * Defines the usable parameters provided by this class.
     */
    public function defineParams()
    {
        return [
            'name' => [
                'title' => 'Name',
                'label' => 'Name of the user',
            ],
            // ...
        ];
    }

    public static function makeParamsFromEvent(array $args, $eventName = null)
    {
        return [
            'user' => array_get($args, 0)
        ];
    }
}

Creating Action classes

Action classes define the final step in a notification and subsequently perform the notification itself. Some examples might be sending and email or writing to the database.

class SendMailTemplateAction extends \RainLab\Notify\Classes\ActionBase
{
    /**
     * Returns information about this event, including name and description.
     */
    public function actionDetails()
    {
        return [
            'name'        => 'Compose a mail message',
            'description' => 'Send a message to a recipient',
            'icon'        => 'icon-envelope'
        ];
    }

    /**
     * Field configuration for the action.
     */
    public function defineFormFields()
    {
        return 'fields.yaml';
    }

    public function getText()
    {
        $template = $this->host->template_name;

        return 'Send a message using '.$template;
    }

    /**
     * Triggers this action.
     * @param array $params
     * @return void
     */
    public function triggerAction($params)
    {
        $email = 'test@email.tld';
        $template = $this->host->template_name;

        Mail::sendTo($email, $template, $params);
    }
}

A form fields definition file is used to provide form fields when the action is established. These values are accessed from condition using the host model via the $this->host property.

# ===================================
#  Field Definitions
# ===================================

fields:

    template_name:
        label: Template name
        type: text

An action may choose to provide no form fields by simply returning false from the defineFormFields method.

public function defineFormFields()
{
    return false;
}

Creating Condition classes

A condition class should specify how it should appear in the user interface, providing a name, title and summary text. It also must declare an isTrue method for evaluating whether the condition is true or not.

class MyCondition extends \RainLab\Notify\Classes\ConditionBase
{
    /**
     * Return either ConditionBase::TYPE_ANY or ConditionBase::TYPE_LOCAL
     */
    public function getConditionType()
    {
        // If the condition should appear for all events
        return ConditionBase::TYPE_ANY;

        // If the condition should appear only for some events
        return ConditionBase::TYPE_LOCAL;
    }

    /**
     * Field configuration for the condition.
     */
    public function defineFormFields()
    {
        return 'fields.yaml';
    }

    public function getName()
    {
        return 'My condition is checked';
    }

    public function getTitle()
    {
        return 'My condition';
    }

    public function getText()
    {
        $value = $this->host->mycondition;

        return 'My condition <span class="operator">is</span> '.$value;
    }

    /**
     * Checks whether the condition is TRUE for specified parameters
     * @param array $params
     * @return bool
     */
    public function isTrue(&$params)
    {
        return true;
    }
}

A form fields definition file is used to provide form fields when the condition is established. These values are accessed from condition using the host model via the $this-&gt;host property.

# ===================================
#  Field Definitions
# ===================================

fields:

    mycondition:
        label: My condition
        type: dropdown
        options:
            true: True
            false: False

Model attribute condition classes

Model attribute conditions are designed specially for applying conditions to sets of model attributes.

class UserAttributeCondition extends \RainLab\Notify\Classes\ModelAttributesConditionBase
{
    protected $modelClass = \RainLab\User\Models\User::class;

    public function getGroupingTitle()
    {
        return 'User attribute';
    }

    public function getTitle()
    {
        return 'User attribute';
    }

    /**
     * Checks whether the condition is TRUE for specified parameters
     * @param array $params Specifies a list of parameters as an associative array.
     * @return bool
     */
    public function isTrue(&$params)
    {
        $hostObj = $this->host;

        $attribute = $hostObj->subcondition;

        if (!$user = array_get($params, 'user')) {
            throw new ApplicationException('Error evaluating the user attribute condition: the user object is not found in the condition parameters.');
        }

        return parent::evalIsTrue($user);
    }
}

An attributes definition file is used to specify which attributes should be included in the condition.

# ===================================
#  Condition Attribute Definitions
# ===================================

attributes:

    name:
        label: Name

    email:
        label: Email address

    country:
        label: Country
        type: relation
        relation:
            model: RainLab\Location\Models\Country
            label: Name
            nameFrom: name
            keyFrom: id

Save to database action

There is a dedicated table in the database for storing events and their parameters. This table is accessed using the RainLab\UserPlus\Models\Notification model and can be referenced as a relation from your own models. In this example the MyProject model contains its own notification channel called notifications.

class MyProject extends Model
{
    // ...

    public $morphMany = [
        'my_notifications' => [
            \RainLab\UserPlus\Models\Notification::class,
            'name' => 'notifiable'
        ]
    ];
}

This channel should be registered with the RainLab\Notify\NotifyRules\SaveDatabaseAction so it appears as a related object when selecting the action.

    SaveDatabaseAction::extend(function ($action) {
        $action->addTableDefinition([
            'label'    => 'Project activity',
            'class'    => MyProject::class,
            'relation' => 'my_notifications',
            'param'    => 'project'
        ]);
    });

The label is shown as the related object, the class references the model class, the relation refers to the relation name. The param defines the parameter name, passed to the triggering event.

So essentially if you pass a project to the event parameters, or if project is a global parameter, a notification model is created with the parameters stored in the data attribute. Equivalent to the following code:

$myproject->my_notifications()->create([
    // ...
    'data' => $params
]);

Dynamically adding conditions to events

Events can be extended to include new local conditions. Simply add the condition class to the event $conditions array property.

UserActivatedEvent::extend(function($event) {
    $event->conditions[] = \RainLab\UserPlus\NotifyRules\UserLocationAttributeCondition::class;
});
1.2.1

Improve support with October v3

May 13, 2022

1.2.0

Adds delayed execution to actions

Feb 26, 2022

1.1.2

Fixes collisions with language keys in compose mail action

Dec 01, 2021

1.1.1

Fixes missing template bug when saving notification rule

Dec 01, 2021

1.1.0

Fixes support for October CMS 2.0

Aug 20, 2021

1.0.3

Added Turkish & Russian translations, various bug fixes.

Mar 20, 2020

1.0.2

Fixes crashing bug.

Sep 22, 2017

1.0.1

First version of Notify

Sep 11, 2017