|
The notifications and collaboration module handles how events in the application are notified to its users. Events are classified in event types. An event type is defined by an entity and a type name.
The event type is something that happens to the entity defined in it. For example, for the “the invoice XXX is about to expire” event, the entity is “Invoice” and the name is “About to expire”. In the “the price of the Product YYY was changed” event, the entity is “Product” and the name is “Price changed”.
The event type is used to define how events should be processed. In particular, the event type is used to configure:
-
The delivery media that will be used when the event happens.
-
The users that will be notified.
-
The message templates that will be used when creating notifications for users.
Each event type may be notified using different delivery media. The event type configuration contains a list of delivery media available for that type. These are the only event media that may be used to send notifications related to the event type.
 |
| Delivery media available for an event type |
When it comes to who should receive notifications for events, two types of events can be found:
Examples of private events are: “There’s a purchase order pending your authorization”, “Your message was replied”.
Examples of public events are: “The invoice X is overdue”, “The account Y is overdrafted”.
The Type Distribution property in the event type is used to define each event type behaviour.
The options are:
-
Public Subscribers: the event is public, users may subscribe to it.
-
Specified in Event: the event is private, only those specified in the event declaration should receive notifications.
When Public Subscribers is selected, users can be added in the “Subscribers” section of the event type. Users can also subscribe to the event manually.
 |
| Subscribers for an event type |
When Specified in Event is selected, the users to whom the notifications will be delivered will be decided when the Event is created.
For example, for the Event “The order XXX was authorized”, the notification could be sent to the user who placed the order. In the creation of the event, the user who placed the order should be added to the user collection.
The message sent in each delivery media will vary depending on the media’s characteristics. As an example, the contents of an E-Mail message and the contents of a web notification for the same event will surely be different, as their length and their context is very different.
When declaring an event the developer does not know how the notifications will be sent. Because of this, the developer cannot define the contents of each message at that time. Instead, the developer adds a set of relevant data to the event declaration, and the final message is defined when processing the event.
To create the final messages, the notifications module uses the “Message templates” in the event type configuration. These message templates contain placeholders that will be replaced by the values of the relevant data.
For example, for the “The price of the Product Y was changed” event, when the notification is delivered the user would like to know the product, the previous price, and the new one.
In this case, the relevant data would be “ProductDescription”, “OldProductPrice”, and “NewProductPrice”.
A sample template could be:
The price of the product %ProductDescription% was changed. The previous value was %OldProductPrice%. The new value is %NewProductPrice%.
The parts in bold will be replaced with the corresponding values.
What happens when the same event is fired twice in the application? Some events should not be notified every time they happen to avoid overloading the user with useless notifications.
For example, the “the account balance is negative” event should be notified once the balance is negative, but it should not be notified after each movement while the account remains with a negative balance, as this may flood the user with useless notifications.
As an opposite example, consider a “your message was replied” event. In this case, the user will probably want to receive a notification each time the message is replied.
The event type policy can be used to determine how events are processed when another event of the same type is already active.
Possible values are:
|