8 Mar
2017
8 Mar
'17
1:55 p.m.
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 <thomas.mortagne(a)xwiki.com>om>:
On Wed, Mar 8, 2017 at 12:27 PM, Guillaume Delhumeau
<guillaume.delhumeau(a)xwiki.com> wrote:
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
--
Thomas Mortagne
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
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 <thomas.mortagne(a)xwiki.com>om>:
> On Wed, Mar 8, 2017 at 11:55 AM, Guillaume Delhumeau
> <guillaume.delhumeau(a)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-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 (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
--
Thomas Mortagne