Skip to Content

Activity Stream Refactoring 6.2 Use Cases

Last modified by Vincent Massol on 2024/11/19 16:13

 XWiki
 Requirements
 Dormant
 
 

[xwiki-users] [Feedback] Activity Stream http://markmail.org/thread/6phvvdu7vvpbay5y (Apr 8, 2013)

 

Initial version requirements http://design.xwiki.org/xwiki/bin/view/Improvements/ActivityStreamRequirements

Description

Extensibility

UC: Support proper display of events, based on their types. Don't just show 'page created', but show 'wrote a new blogpost' or 'created a new task', etc. Failed to execute the [groovy] macro. Cause: [startup failed: Script1119.groovy: 14: unable to resolve class XmlParser  @ line 14, column 12.     def xml = new XmlParser().parseText(cont)               ^  1 error ]. Click on this message for details.
UC: Have an extensible event mechanism, where applications can provide their own new events to AS Failed to execute the [groovy] macro. Cause: [startup failed: Script1120.groovy: 14: unable to resolve class XmlParser  @ line 14, column 12.     def xml = new XmlParser().parseText(cont)               ^  1 error ]. Click on this message for details.
Failed to execute the [groovy] macro. Cause: [startup failed: Script1121.groovy: 14: unable to resolve class XmlParser  @ line 14, column 12.     def xml = new XmlParser().parseText(cont)               ^  1 error ]. Click on this message for details.
UC: Have a mechanism that easily allows applications to define fine-grained application-specific events. e.g. The meeting manager application should be able to easily define that when a meeting is edited and the start date/time is changed a "meeting rescheduled" event should be fired. Same for adding a new member to a meeting. etc. This could be translated to a mechanism that allows to define what properties of an object to watch for changes and what event to fire when those changes happen. This should be a commodity feature so that not every application is required to implement a Document(CRUD)Listener. For more complex operations the listener should still be the go-to solution. Implementation suggestion: 1) define a special XClass for this purpose like we have for UI extensions for example or 2) somehow use hidden form elements in the application's sheet for the standard save action (like xvalidate, etc).
UC: Support a variable list of event parameters (i.e. not limited to param1..param5). Failed to execute the [groovy] macro. Cause: [startup failed: Script1122.groovy: 14: unable to resolve class XmlParser  @ line 14, column 12.     def xml = new XmlParser().parseText(cont)               ^  1 error ]. Click on this message for details.
UC: An application can register as event displayer for a certain XClass or event type.

Display and Navigation

UC: Show more entries option in the UI Failed to execute the [groovy] macro. Cause: [startup failed: Script1123.groovy: 14: unable to resolve class XmlParser  @ line 14, column 12.     def xml = new XmlParser().parseText(cont)               ^  1 error ]. Click on this message for details.
UC: Timeslot based UI: Have a scroller UI element that allows to group events in timeslots defined by the current scroll level. (e.g. 5 minutes, 1 hour, 1 day. Daily view example: http://www.xwiki.org/xwiki/bin/view/Main/ActivityStreamDemo?delay=1440 ). The user should be able to define his starting timeslot range.

Filtering

UC: Filter events both from the UI and through the wiki macro's parameters (persistently) Failed to execute the [groovy] macro. Cause: [startup failed: Script1124.groovy: 14: unable to resolve class XmlParser  @ line 14, column 12.     def xml = new XmlParser().parseText(cont)               ^  1 error ]. Click on this message for details.
UC: Be able to filter events based on a specific XClass (i.e. events related to certain objects or pages containing those objects)
UC: Allow negative filters to be able to exclude certaing events from being displayed.
UC: Allow partial values for filtering instead of only exact values.

Misc

UC: Ability to suppress the storage of events (i.e. ignore them in the back-end when they occur) for a particular stream (wiki/space/page/user/class/etc.)
UC: Grouped events. If a hight level (e.g. xar import, page rename, comment add, etc.) event generates various low-level events (eg. page create, page update, object add, etc.) underneath it, make it easy to only get/display the high level event and skip the low level ones.
UC: For grouped events. Don`t make it impossible to get the low level events, in case they are needed.
UC: Display contextual event data (i.e. a snippet of the actual comment the user just posted, the title of the new blog post, thumbnail of the image the user just attached, etc.)
UC: The Activity Stream should be refreshable individually from the page it is in.
UC: The Activity Stream should refresh automatically on a configured interval.
UC: Ability to be integrated in Apps.
UC: Ability to see page-level activity, as an improved alternative to page history. The advantage is that, instead of having a list of save actions and relying on the save comment in the document history, we can use an AS that properly displays object editing, attachment uploading, commenting, application-specific events, etc.
UC: The event data should be accessible through a REST API that can be easily rendered by a Web UI or a Mobile UI. All the logic should be done by this backend so that the UI only needs to render it.
UC: Automatically and periodically clean old events. Never end up with an empty Activity Stream on any wiki because of this autocleaning. Alternatively, if autocleaning is enabled, AS could display "Activity in the past X months".
UC: Have an admin UI where it's easy to clean events based on a query (between certain dates, for certain users, on certain wikis, etc.).
UC: Be able to perform interventions on a wiki by a support team. Define a list of users that will not have any of their changes recorded in the database. Alternatively, be able to disable the any recording of events.

 

About

About

Support

Platform

User Guide

Admin Guide

Developer Guide

Projects

XWiki

Extensions

Other

Contribute

Status

Practices

Under the Hood

Get Involved

Get Connected