Description

The idea of this design is to gather needs and to brainstorming about a refactoring of the way we are grouping notifications to display them or send them by email.

For the record we already have a working algorithm for grouping notifications, done through an internal component called SimilarityCalculator. This implementation is used for grouping in both email and browser notifications. The problem is that this implementation doesn't allow to provide custom computation especially for extensions.

Usecases

UC1. As a user A, I want two notifications related to same page, with same event type, to be displayed together in the notification area, with the possibility to see them both in the details.

UC2. As a user A, I want two notifications related to same page, with different event type but triggered during same operation to be displayed together in the notification area

UC3. As a user A, I want two notifications not related to a document and having the same type, to be displayed together in the notification area

UC4. As a user A, I want two notifications related to different pages (even if they share same event type) to be displayed separately in the notification area

UC5. As a user A, I want two notifications not related to a document and having different type to be displayed separately in the notification area

UC6. As a user A, I want to receive a single email containing all notifications in a given period, respecting the same grouping properties as UC1,2,3,4,5

UC7. As a user B, I want to receive email notifications grouped per applications only: two notifications should belong to two different emails if they are not triggered by same application

UC8. As a developer I want to express that some custom events should never be grouped together

UC9. As a developer I want to expose my own algorithm for grouping my custom events

UC10. As a developer, I want to be able to express a new way of grouping events specifically for email sending: e.g. I want to perform sub-groups in a specific extension

Open questions

Number of emails to sent

How do we comply between users' will and developers' will? So for example, as a user I always want to receive a single weekly email with a full digest. And as a developer, I want to express that those notifications should not be grouped. IMO users' will should always win, but we need to express this.

So we need at some API level a way to specify that a user wants to always receive a single email (and it should be the default value in case of upgrade), or that they're ok to receive multiple emails. From a UX point of view, we will probably need to introduce a new selector to be able to specify that preferences. Another way of dealing with this would be to always consider that daily/weekly/monthly notification emails are digest and involve a single email, and that live email notifications are never digest so that the various grouping policies could apply, in particular if a descriptor specified that it should never be grouped.

We could also imagine that some custom extensions could change that so that even for daily/weekly/monthly email it's not necessarily a digest.

Brainstorming on the topic: https://forum.xwiki.org/t/email-notification-grouping/12326/

Count of notifications

Right now the way we count notifications in the notification area is linked to the number of composite events: however if we change the way to build those composite events and allow users' to change it dynamically, should we keep that link, or should we on the contrary count the each event individually?

Architecture

Easiest solution seems to perform grouping of notifications as late as possible, so that the different ways of displaying the notifications could chose how to group them. We can imagine in the future that for example we have a grouping strategy for displaying in the notification area, another way for sending email and yet another way for displaying them in the browser.

Then the best solution would be to get rid of CompositeEvent in the main APIs and to only rely on List of events. Then we would have a dedicated role for grouping the list of events that would return maybe a list of CompositeEvents.