To make sure the new notification system provided flexibility in managing notification behavior and ensure feature-parity between the behaviors of Echo and Core, the Core notifications system will add a new pattern: a notifications middleware. The middleware will be invoked on notifications before they are given to the Handler, allowing developers to manipulate notifications or recipients conditionally.
Current behavior: hooks
Currently, notification developers often need to interfere with the behavior of related notifications. This includes actions such as overriding existing notifications, adding secondary notifications, or modifying the recipient list by adding or removing recipients. This is currently achieved using various hooks provided by Core and Echo, with the choice of hook determined by specific business logic requirements.
New approach: the middleware
The notifications middleware provides a unified and consistent single-point-of-entry mechanism to handle notification management by an external system. Developers will have a centralized and standardized way to manage the behavior and recipient lists of notifications between different products. The single entry-point also means easier maintainability and easier way to debug when a problem happens, since all notification modification behavior will go through a single middleware chain.
Middleware details
The middleware is a simple execution of a chain of callable code that can be registered through extension.json. Each middleware code receives an array (Batch) of Notification and RecipientSet objects that the code can manipulate. Each middleware then calls the next middleware in the chain.
Example use cases
There are multiple cases around the system where one notification type needs to intercept another. Here are some examples:
- Suppressing other notifications
- MassMessage blocks mention and flow-mention notifications from being sent when agent is MassMessengerUser
- AchievementBadges blocks thank-you-edit and welcome notifications depends on configuration
- Flow blocks all notifications sent from flow talk page manager user.
- BlueSpice stops watchlist notifications for BlueSpice entities
- Change in behaviour:
Benefits
We anticipate a number of benefits from this new approach:
- Notification developers will have an easier time registering "interference" logic. They will have a single-entry pattern rather than finding which hook to use (from quite a number of hooks)
- In case of bugs, it's easier to check the middleware chain, rather than having to debug multiple hooks
- Since the middleware handles arrays of notifications ("Batch"), then even the action of invoking it at the end of the process would mean we can potentially handle multiple notifications that result from the same action in the same batch and allow middleware to decide which is prioritized.