On Wed, Mar 8, 2017 at 11:55 AM, Guillaume Delhumeau <guillaume.delhum...@xwiki.com> wrote: > 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/e5a3cc7b6a5cbe82b1668d9d30fbf6a61b026046/xwiki-platform-core/xwiki-platform-eventstream/src/main/java/org/xwiki/eventstream/NotificationConverter.java#L36-L36 > > * 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/81172b2dfd994ddd727efe93daf8fa446dc4abce/xwiki-platform-core/xwiki-platform-activitystream/xwiki-platform-activitystream-api/src/main/resources/activitystream.hbm.xml#L63-L63 > > * 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/e5a3cc7b6a5cbe82b1668d9d30fbf6a61b026046/xwiki-platform-core/xwiki-platform-eventstream/src/main/java/org/xwiki/eventstream/EventStatus.java#L25-L25 > See: > https://github.com/xwiki/xwiki-platform/blob/81172b2dfd994ddd727efe93daf8fa446dc4abce/xwiki-platform-core/xwiki-platform-activitystream/xwiki-platform-activitystream-api/src/main/resources/activitystream.hbm.xml#L69-L69 > > * 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.png > > * 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.
You already have a starting date in each profile, the profile page creation date. > > Do you see any problem with that vision? > > Thanks you, > > -- > Guillaume Delhumeau (guillaume.delhum...@xwiki.com) > Research & Development Engineer at XWiki SAS > Committer on the XWiki.org project -- Thomas Mortagne
