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 <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
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
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
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the