dm4-subscription: upgrade to be compatible with DM 4.8.x

[Malte]

Depends on #823 and #824.

[Malte]

I would like to revise the model of the subscription plugin and since the extended meta-model was lately extended i wanted to ask those who know the new meta model on how to improve the following type definition. Also the Facets Module may be more appropriate to use when epxressing our message publish and subscribe scenario, but i am not exactly sure.

So the basic logic behind this service is that:

• A Subscription is managed by the existence and specification of a Subscription edge between a User Account Topic and any other Topic.
• A new Notification, when "send" via the SubscriptionService?, is created, set unseen and directly related with a "Notification Recipient" edge to all subscribers.
• The Subscribed Item ID (type/field) allows us to tell, just by the look to the Notification, which users subscribed to the involved item and how ("In App" or "Mail).
• Note: The "User Account Topic" is held as part of the "Notification" to express who triggered it, who actually did the change to the subscribed topic and useful when displaying a notification to a user.

Here is the current type definition:

Topic Type: Notification
   Title              (Text, Composition)
   Body               (HTML, Composition)
   Involved Object ID (String, Composition)
   User Account Topic (Topic, Aggregation)
   Subscribed Item ID (String, Composition)
   Notification Seen  (Boolean, Composition)

Association Type: Subscription
  Subscription Type: "In App" or "Mail" (Text, Aggregation, Many)

Association Type: Notification Recipient (Number)

The Notification is the message involving all information who (user) changed (action) what (title) on which (involved object id) topic or association. The (body) is merely there for informational purpose and up to the plugin developer using the subscription service to fill with data as she needs.

Any ideas on how i should at best revise this or any needs for extending this service from your perspective as a plugin developer? Thanks for sharing your toughts.

[Malte]

Furthermore, one thing to add, the subscription module currently depends on the "dm4-tags" module to allow indirect subscription, that is a user subscribing to a "Tag" topic, ultimately describes to all changes made to all topics tagged with this item, which is quite a powerful feature, developed to allow thematic subscriptions.

Note: I would add "dgf, jri and JuergeN" to this ticket if i would be a allowed to in this Trac.

[JuergeN]

Malte, you have admin rights in trac (since the very beginning).

[Malte]

No i never had, it was just you all were thinking i had admin rights in trac ;D

Getting back to the topic, to provide a bit of background on WHY we wanted to persist "notifications" to users:

"Notifications" were broadcasted to all connected websockets clients BUT not all users to be notified were ONLINE at the time of notification. Hence, we wrapped the notification (message) into a topic and equipped it a "SEEN" flag (which all clients rendering notifications to users need to manage for them). The other attributes were merely, as said, to provide context around the notification/message.

I was thinking about that someone would want to "subscribe" a DM Workspace or to the "publication" of data into "public" workspaces/ or by certain users, but i wanted to ask you first. Thanks for sharing your thoughts.

[Malte]

As soon as "Email Address" of users are stored in a "Collaborative" workspace, like with the current dm4-sign-up module, notifications can not be sent out via "Email" to users (see also #934).
Copying comment into the correct ticket. I wrongly posted the following message as a comment to #934.

To allow users subscribe to changes in DeepaMehta with their email we would either (1) need to provide plugin developers privileged access to "Email Address" topic values.

The idea which we should support is imo: If a subscription exists and another user triggers a notification through her actions on a topic, the system should be able to notify the subscribed user (potentially per Email) without revealing the recipients Email address value to the user who triggered the notification. Drawback: In this approach secrecy of any given email-address would solely be kept if the plugin develoeprs implement such a privileged call responsibly. I think this is the way to go.

Any thoughts on this? Do we need or want "Email" based notifications/messages among DM 4 users?

[jri]

What is the status quo here?
Do you need any further support?

[Malte]

Regarding support for an email based notifications i think we're fine with the new getEmailAddres(username) function.

At the moment i am reading about "notifications" in general and i am still not sure which _updates_ or rather _creates_ we want users allow to sign up for. For example, subscribing to "Topicmap" updates might not be very useful and potentially very verbose (e.g. collaborators move topics and reveal new assocs a lot).

A first case which could be interesting to support might be something like:
Allowing to set up a "Subscription Edge" between a "Workspace" and a "Username" and then e.g. allow for indirectly listening for whats happening in that workspace, e.g. for the creation of new topicmaps.

But i am not sure about when i would have like to receive notifications at all, yet. If you have any useful suggestions here i would be happy to hear about them. In general, i think its important that we have subscriptions very flexible for end users but i am not sure who far we should try to go here.

Regarding the "In App" subscription edge (another option than subcribing per "Mail") type i just started looking at the operating system notification integration (see the ​HTML 5 spec at MDN).

[Malte]

So, as i see it, as no changes were proposed there is nothin in the way anymore for an upcoming release of this plugin.

There is even the possibility to more easily advance the "In App" notifications thanks to the progress made in #823.

[Malte]

Now i am really excited for the upcoming release (1.1) of this very small but powerful plugin.

The plugin is now named dm4-notifications as this name better reflects on what this plugin actually is about: Everything around managing the Topic Type "Notification".

For the moment all "Notification Subscription" are regarded as "In-App". So there is no connection to any Email functionality yet. To deliver notifications there is also no special gui (yet) but you can find all personal "Notifications" in the "Private Workspace" and related to your "Username" via the Webclient.

For builing a simple javascript client (possibly even using the HTML 5 desktop integration as linked in above) to deliver notifications to users (and set those as "seen") could use the REST API of this plugin to fetch all "unseen" notifications for a user. This could be done straight after log in or whenever a broadcast comes around from the websockets-service.

Currently (using the ​1.1-SNAPSHOT and DM 4.8) a user, to receive automatic notifications, can create a "Notification Subscription" between her "Username" and ..

• a "Workspace" -> leading to notifications on new topicmaps (which are not private) created in that workspace
• a "Topicmap" -> leading to notifications created for every "topic added" to that topicmap

Many usability issues remain for listing and interacting with notifications (for example custom renderer should allow to reveal the new topic or topicmap directly, sorting by creation date etc.) but the foundations are basically working. A first release will come with the end of this week. Feel free to leave your thoughts on that here.

[Malte]

For more infos and hints on usage please find the README at:
​https://github.com/mukil/dm4-notifications#deepamehta-4-notifications

Closing ticket.