Sure but it won't work when you upgrade an old wiki with users created years ago. We would still end up with thousands of unread notifications.
2017-03-08 12:07 GMT+01:00 Thomas Mortagne <[email protected]>: > On Wed, Mar 8, 2017 at 11:55 AM, Guillaume Delhumeau > <[email protected]> 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 ([email protected]) > > Research & Development Engineer at XWiki SAS > > Committer on the XWiki.org project > > > > -- > Thomas Mortagne > -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
