Re: [xwiki-devs] [Proposal] XWiki Watch publicly available on xwiki.org

On Jul 24, 2008, at 2:48 PM, Anca Paula Luca wrote: > Vincent Massol wrote: >> On Jul 24, 2008, at 9:35 AM, Anca Paula Luca wrote: >> >>> Vincent Massol wrote: >>>> On Jul 23, 2008, at 5:40 PM, Anca Paula Luca wrote: >>>> >>>>> Hi devs, >>>>> >>>>> As it has been already mentioned a couple of times, I strongly >>>>> believe >>>>> that XWiki Watch should be accessible in a sandbox on xwiki.org, >>>>> for >>>>> everyone to try it out and explore its features and for us to >>>>> get an >>>>> open real-life test of it. >>>>> There is a document dedicated to the issues that might prevent >>>>> this at >>>>> http://watch.xwiki.org/xwiki/bin/view/Development/ >>>>> XWatchOnXWikiOrg , >>>>> please fill it in with any opinions you have! >>>>> >>>>> Here's my +1 for having an installation of XWatch publicly >>>>> available >>>>> on >>>>> xwiki.org, WDYT? >>>> Sure, we've already discussed it as I wanted to install it but >>>> discovered it wasn't possible at the time. I wouldn't call it a >>>> sandbox as I think it could be used for real and contain feeds >>>> related >>>> to xwiki and anything relevant. >>>> >>>> Here are some issues I can think of: >>>> 1) Allow unregistered users to view and use the reader >>> Since Watch is implemented using the XWiki documents & objects >>> model, user >>> rights follow the same model as all XWiki. Guest users use the >>> rights we give >>> them: for viewing / navigating through the reader, view right is >>> enough, whereas >>> any edit (add feed, tag/flag/trash/mark as read articles) requires >>> edit rights. >>> Unless there is a problem with giving edit rights to guests, I >>> don't >>> see exactly >>> what is the issue with having guests use the reader. >> Yes we definitely shouldn't give edit rights to guests. This >> leads to >> spamming. We need people to be registered for getting edit rights. >> >> But if users can use the reader with only view rights then it's >> good. >> AFAIR it wasn't working before. >> >>>> 2) Provide ability to undo changes done by users (the revert >>>> feature >>>> of all wikis). This is especially important in a public instance: >>>> it >>>> needs to be easier to revert an error than it is to create one! >>> As mentioned earlier, all Watch data is stored in xwiki >>> documents & >>> objects, so >>> reverting is as easy as it can be in any other instance of xwiki. >>> >>> Now, there is a problem with what we understand by reverting >>> changes >>> in a "feed >>> reader". The first example that comes into my mind is when a user >>> adds a feed >>> source, say unwanted. Since the feed articles fetched from that >>> are >>> stored in >>> xwiki documents, revert (wiki-way) would mean deleting the feed, >>> but >>> that would >>> not trigger deleting all fetched articles. While from a feed >>> reader >>> point of >>> view, reverting this change would probably mean deleting all >>> fetched >>> articles >>> too. For this particular example this is not a problem because >>> deleting a feed >>> with all fetched articles is implemented in watch reader >>> interface, >>> but there is >>> a general problem of actions and concepts interpretation in Watch: >>> seeing it as >>> a wiki vs. seeing it as a feed reader. >> We just need to check use case by use case if we have a way to >> revert >> changes: >> * If a user adds an unwanted feed, we can remove it with the delete >> feed button so that's ok >> * if a user deletes a feed, how can we restore it? > A feed is an object in a XWikiDocument, so restoring from recycle > bin would work > perfectly fine. Same for deleted articles, groups, keywords. > >> * if a user creates a spammy comment or tag how can we remove them? >> * can a user remove a tag or comment? (probably not or maybe only >> his >> own tags/comments) >> * same questions for the trash and starring. > A comment for an article is a xwiki comment for the document holding > the > article, the tags, star, trash are properties of the article object. > So any > change can be rolledback through the wiki interface. The problem is that the exposed interface is the Feed Reader one so I guess we could need some simple access to the underlying wiki pages or some admin buttons to revert changes easily.