On 11/07/2010 01:47 AM, Sergiu Dumitriu wrote: > On 11/04/2010 03:52 PM, Jerome Velociter wrote: >> Hey, >> >> Wild idea... could we skip those events ? >> >> It feels weird that before logging in the first time you have "No >> recent activity", and once you log-in (or refresh the page probably) >> you have like 12 technical pages created by some Admin or by guest... >> In my opinion, we could keep the feed empty until users do their first >> modifications. > > +1. > >> Now from an implementation point of view, that's another story, it >> might not be easy to do it nicely. Maybe we could add yet-another >> saveDocument() that skips sending AS events (or is there one already >> ?). > > I didn't feel good about adding such a method, since it might be used to > bypass recording activity. > > I'd rather add a SystemEvent that marks system activities, like > auto-creating classes, updating the scheduler fire date, auto-posting > blogs on a scheduled time.
Hm, I'm actually starting to see even more benefits to this idea. We could use the same recent activity macro to list system events somewhere in the administration part, where we could also see live upgrades performed by the future extension manager, extension add/remove activity, configuration changes, etc. >> Bottom line is that I would not feel confident explaining someone how >> those activities appeared out from the blue on first login/refresh. >> >> WDYT ? >> >> Jerome. >> >> On Thu, Nov 4, 2010 at 1:40 PM, Stefan >> abageru<[email protected]> wrote: >>> Hi devs ! >>> >>> I had a look at this and the problem is indeed what Raluca suggested. >>> However, if i set the $event.user to superadmin, I will get the same >>> situation as with XWikiGuest...that is a clickable icon that leads to >>> nowhere. >>> >>> So, do you think I should maybe place XWiki.Admin as the creator of >>> those classes that appear in the Recent Changes on a first run ? >>> >>> Stefan >>> >>> >>> On 11/02/2010 02:27 PM, Raluca Stavro wrote: >>>> Hello, >>>> >>>> The reason why XWikiGuest is being displayed by default on a fresh >>>> XWiki >>>> instance is the fact that activitystream plugin sets as user for >>>> pages like >>>> 'XWiki.SheetClass', the guest user instead of superadmin user. >>>> Previously, >>>> on the Recent Changes old implementation, there was a query to the >>>> database, >>>> searching for doc.author, and this author is properly set >>>> ('superadmin') on >>>> such documents. >>>> So the things look like this: >>>> - $event.user: XWiki.XWikiGuest >>>> - $xwiki.getDocument($event.page).author: superadmin >>>> >>>> This is a core issue and Stefan will take a look on it. >>>> >>>> Raluca. >>>> >>>> >>>> On Mon, Nov 1, 2010 at 10:58 PM, Vincent Massol<[email protected]> >>>> wrote: >>>> >>>>> Hi devs, >>>>> >>>>> Good job with the recent activity implementation! >>>>> >>>>> I've noticed that when you build XE from trunk and run it, you see >>>>> all the >>>>> pages with an author of XWikiGuest. I would have expected to see >>>>> them with >>>>> an author of Administrator. Is that a bug? Maybe it's not related >>>>> to the >>>>> recent activity implementation but it doesn't sound right anyway. >>>>> >>>>> Also if I click on XWikiGuest it goes to a non existing page (since >>>>> XWikiGuest user doesn't exist). I think we shouldn't make XWikiGuest >>>>> clickable. > > -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
