Wiki source code of Notifications System - Requirements
Last modified by Vincent Massol on 2024/11/19 16:12
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | We're going to need to revamp the notification system to make it more scalable. It will be useful both to improve existing features and to create a sound base for new features. This revamp should be based on activity stream instead of queries. This means that the system works in three phases: | ||
| 2 | |||
| 3 | 1/ Users subscribe to channels 2/ Channels are recorded 3/ Channels are output in the desired format by the user | ||
| 4 | |||
| 5 | == Available Channels == | ||
| 6 | |||
| 7 | * All the wikis in a XEM | ||
| 8 | * All activity in the Wiki | ||
| 9 | * All activity in a space | ||
| 10 | * All activity of a list of chosen pages | ||
| 11 | * All activity of a given user | ||
| 12 | * All activity of a given user's friends (optional/future) | ||
| 13 | * All activity in a tag (optional/future) | ||
| 14 | * All activity in a search (optional/future) | ||
| 15 | * All activity in a tag of XWiki Watch (optional/future) | ||
| 16 | |||
| 17 | Extensibility | ||
| 18 | |||
| 19 | * Developers / admins should be able to create additional channels. Those new channels should be automatically detected and will have the same subscription and output options as existing channels | ||
| 20 | * Example: the collection plugin provides new channels for Workpackages and Workpackage categories. Users can subscribe to either of those channels either by email or via RSS. | ||
| 21 | |||
| 22 | == Subscription == | ||
| 23 | |||
| 24 | * From his Watch area the user can decide to receive notification for the whole XEM or the whole Wiki | ||
| 25 | * From the Watch menu he can subscribe to the current space or page | ||
| 26 | * From the tags page he can subscribe to a given tag | ||
| 27 | |||
| 28 | There can be multiple type of subscriptions using the same channel. The subscription system should be extensible. | ||
| 29 | |||
| 30 | Based on the subscription configuration we get a list of channels a user is subscribed too. | ||
| 31 | |||
| 32 | == Notification feed outputs == | ||
| 33 | |||
| 34 | * RSS | ||
| 35 | * Emails | ||
| 36 | |||
| 37 | Optionally the RSS and emails should provide nice display of differences for each update. | ||
| 38 | |||
| 39 | The RSS feeds can be broken down by subscription or maybe channels. | ||
| 40 | |||
| 41 | == Implementation == | ||
| 42 | |||
| 43 | There are two types of channels | ||
| 44 | |||
| 45 | === Shared === | ||
| 46 | |||
| 47 | The channel is created only once for all users and security is checked at RSS or emails generation time | ||
| 48 | |||
| 49 | == Personal == | ||
| 50 | |||
| 51 | The channel is personal and created when the update are happening. It is for use only by one person. | ||
| 52 | |||
| 53 | == Example == | ||
| 54 | |||
| 55 | === Monitoring a whole wiki === | ||
| 56 | |||
| 57 | 1/ We record a channel per space 2/ One user subscribes to the whole wiki 3/ This means he monitors the channels corresponding to each space 4/ He can get an RSS feed by space or for his full subscription (the wiki) 5/ He will get an email showing him the results for the channels he is subscribed to (by space) | ||
| 58 | |||
| 59 | === Monitoring a list of pages === | ||
| 60 | |||
| 61 | ==== Approach 1 ==== | ||
| 62 | |||
| 63 | In this approach we take a subset of prerecorded channels | ||
| 64 | |||
| 65 | 1/ We record a channel per space (the page items are listed) 2/ One user subscribes to a list of pages 3/ He can get a RSS feed generated based on a match of the pages he subscribed to 4/ He can get an email showing the result by matching the pages he subscribed to | ||
| 66 | |||
| 67 | ==== Approach 2 ==== | ||
| 68 | |||
| 69 | In this approach we create the user personal Watch channel | ||
| 70 | |||
| 71 | 1/ The user configures his personal channel by setting a list of pages to monitor 2/ We record in this channel the modifications to the pages he subscribed to 3/ The user can get and RSS feed or email for his personal channel | ||
| 72 | |||
| 73 | Approach 2 has the benefit of simplifying the system (no sub query inside a channel) | ||
| 74 | |||
| 75 | === Monitoring a list of tags === | ||
| 76 | |||
| 77 | ==== Approach 1 ==== | ||
| 78 | |||
| 79 | In this approach we create a channel per tag | ||
| 80 | |||
| 81 | ==== Approach 2 ==== | ||
| 82 | |||
| 83 | In this approach we had the matching pages to the user's personal channel | ||
| 84 | |||
| 85 | == Proposed Technical Architecture == | ||
| 86 | |||
| 87 | === ActivityStreams notifications === | ||
| 88 | |||
| 89 | Activity are the streams which will store the information in the backend | ||
| 90 | |||
| 91 | * \\ | ||
| 92 | ** XEM Activity Stream | ||
| 93 | ** Wiki Activity Stream | ||
| 94 | ** Tag Activity Stream (maybe) | ||
| 95 | ** Personal Activity Stream | ||
| 96 | ** Friends Activity Stream (maybe) | ||
| 97 | |||
| 98 | === Subscriptions === | ||
| 99 | |||
| 100 | Subscriptions are the way notifications are organized from a user point of view. We need to decide if subscriptions are grouped together or more segmented. | ||
| 101 | |||
| 102 | There can be the following subscription types | ||
| 103 | |||
| 104 | * All wikis (xem) | ||
| 105 | * All wiki (wiki:wikiname) | ||
| 106 | * Wiki space (space:wikiname:space) | ||
| 107 | * Page (page:wikiname:page) | ||
| 108 | * Tag (tag:wikiname:tag) | ||
| 109 | * Collection (collection:wikiname:collection) | ||
| 110 | * Collection Category ( collectioncategory:wikiname:categoryname:categoryvalue) | ||
| 111 | * Friends (friends) | ||
| 112 | |||
| 113 | Certain subscription types need particular channels to work. | ||
| 114 | |||
| 115 | A user can create multiple subscription which have a schedule. Subscription items can be grouped into subscription sections (for display) |
