Actually, all existing entries in the Activity Stream are considered as notifications, as soon as there is a descriptor for their type (in my screenshot, we see only "notifications" that are actually activities from AS).
I know that existing events do not implement the "StorableEvent" interface, but all events that are currently saved in AS are de-facto "storable". Said differently, the notion of notification is merged with the notion of Event/Activity. The only difference is the way we display them. 2017-03-08 13:31 GMT+01:00 Thomas Mortagne <[email protected]>: > 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-Notificati > onsMenu.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 > -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
