Re: [xwiki-devs] [Proposal] Notifications - Round 2

Hello everybody. *TL;DR:* Notifications are nothing but standard Events from the Observation Manager, marked as "Storable" and stored by the Event Stream. They can be displayed in the top bar of the wiki and/or sent by e-mails periodically. Since this is overlapping with the Watchlist features, the idea in the future is to re-implement the watchlist using the notification mechanism and to push the current Watchlist module to contrib. Need your agreement to go in that way. *Background:* A few weeks ago I've sent a proposal about the Notifications feature. I've made some work since, and talked with Vincent to define a vision. Let me introduce you what I've already done and what I'm going to do in the following days: * I am going to introduce 2 interfaces: *StorableEvent* and *TargetableEvent* (currently I have only implemented a *NotificationEvent* that represent both). * *StorableEvent*: when an event from the Observation Manager implements this interface, it means this event will be logged (stored) by the Event Stream. * *TargetableEvent*: introduce a list of "targets", which are the IDs of the entities who are targeted by this event. Example: when someones replies to your forum topic, an event called "someone has answered to your topic" is sent with the topic creator as target. * As I said, storable events are stored by the Event Stream, which is currently implemented by the Activity Stream module. So it means a *StorableEvent* is currently stored as an *ActivityEvent* but this remains technical and not visible from the outside. * I have introduced the role *StorableEventConverter* which convert a *StorableEvent* to an Event from the Event Stream. Each application can provide its own converter (to store additional parameters for example) but there a default one that is used if nothing else is defined. See: https://github.com/xwiki/xwiki-platform/blob/e5a3cc7b6a5cbe82b1668d9d30fbf6… * I have added the "target" field (a list of string) to the Event and the *ActivityEvent* classes. I have also updated the hibernate mapping for *ActivityEventImpl* accordingly. See: https://github.com/xwiki/xwiki-platform/blob/81172b2dfd994ddd727efe93daf8fa… * I have introduced an *EventStatus* class (and *ActivityStatusImpl*) to store in the wiki which notifications has been seen by a specified user. This is important because we want to distinguish new notifications from those the user have marked as read. Hibernate mapping has been updated as well in the Activity Stream module. See: https://github.com/xwiki/xwiki-platform/blob/e5a3cc7b6a5cbe82b1668d9d30fbf6… See: https://github.com/xwiki/xwiki-platform/blob/81172b2dfd994ddd727efe93daf8fa… * I am going to introduce the *StorableEventDescriptor* role. The components will give some meta-information about a storable event: the pretty name of the event, the application that can send it and a short text giving a description about the event. We need this to expose to the user the list of events that she can subscribe to. (Right now I have implemented this as XObjects called "*NotificationType*" which is an error) * I have introduced the concept of NotificationPreference. It's an XObject stored in the user profile. When a user wants to subscribe to a particular type of event, this xobject is created with the id of the event and the media used for the notification ('web notification', 'email' or both). In the future, this preferences should handle some more precise filters. Like: "I am interested in the notifcations sent by the Forum Application but only when it comes from the wiki A and not the wiki B." * I have introduced the role *NotificationDisplayer*. It's a component that generates the XDOM to display in the notifications menu. Each application can implement its own displayer, but failback to a default one. * The *DefaultNotificationDisplayer* tries to render the template 'notifications/{eventType}.vm' and failback to 'notifications/default.vm'. It means you can create your own displayer either by implementing a custom *NotificationDisplayer* or by creating a template in the right location. * The *NotificationManager* is responsible for getting the notifications for the current user, according to its preferences. * I have implemented a UI which load the notification asynchronously and display them in the notification menu, just below the watchlist options. See: http://jira.xwiki.org/secure/attachment/33586/WIP-NotificationsMenu.png * Unread notifications are displayed with a different styling that others. * The user has the ability to mark a notification as read. * I have implemented a preferences page in the user profile, which list all *StorableEventDescriptor*. See: http://jira.xwiki.org/secure/attachment/33587/WIP-NotificationsPreferences.… * As a proof of concept, I am going to make the Blog Application send some custom events that will be displayed in the notifications menu. Problems: * We clearly have some overlapping of concerns with the Watchlist. The UI is even very bad since the Watchlist options are displayed in the same "bell" menu than the notifications without being connected together. It's confusing. * That is why we propose, with Vincent, to remove the Watchlist as it is, and re-implement its feature using the notifications abilities. * The email sending is not implemented yet, and will not for the 9.2 release. * We don't have a filter to not display similar notifications. For example, a user saving a document 10 times in 10 minutes will generate 10 notifications. Possible flooding. * When a user registers, all the notifications that are stored since the beginning of the wiki are unread by her. It does not make sense to tell her "you have 1 000 000 000 unread notifications" so we need to store a starting date for each user.

Do you see any problem with that vision? Thanks you, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project