Event expiration and cancelation

Events are declared by the developer when certain criteria are met. For example, when an order is placed and requires authorization, the developer may declare an “order requires authorization” that will be notified to the users that may authorize it.

What should happen after the order is authorized by one of these users? It would be confusing for the rest to receive a notification for scenario that is no longer valid.

The same could be said for the “Invoice is about to expire” event. After the invoice expired, this event is no longer valid (maybe it should be replaced by an “invoice expired” event).

The event lifecycle is introduced to handle this scenarios. After an event is declared it enters its “Active” state. While in this state, the notifications module will try to notify users about it.

The developer can choose to cancel an event in the “Active” state. When doing this, the event will be moved to a “Cancelled” state and notifications will no longer be processed for that event.

The developer can also choose to include an expiration date in the event. After this expiration date, the event will be considered cancelled as well.

In the examples above, the developer should cancel the “order requires authorization” event after it is authorized, and the developer should configure the “Invoice is about to expire” event so that it expires when the invoice expires.

The result of cancelling an event varies depending on the delivery media used.
  • E-mail: messages already sent will reach the user as usual, messages that have not been sent yet will not be sent. The latter case usually happens when delivery failed for the message and the module is retrying.
  • Web Notifications: Only notifications for active events are shown.