On Wed, Mar 8, 2017 at 12:27 PM, Guillaume Delhumeau <[email protected]> wrote: > 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.
Which notifications ? You will start getting new notifications only when you have new notification system, no ? > > 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 -- Thomas Mortagne
