[Building Sakai] distinct events for Resources and Dropbox (Sitestats)

[Vijaykumar Sadupally]

This message (and attachments) is subject to restrictions and a disclaimer. Please refer to http://www.unisa.ac.za/disclaimer for full details.

Hi Jim,

Yes, The entity Id's are different. But the events(content.new...) are same, I want to read these two tool events separately in Statistics(Sitestats) tool. Currently the Statistics
is reading Resources tool for the stats. As Unisa uses Drop box and resources as separate tools, want to read the two tool events separately.

Do you have any suggestions. Thank you

Regards
Vijay
Unisa


-----Original Message-----
From: Jim Eng [mailto:jimeng at umich.edu]
Sent: 23 March 2012 15:52
To: Stephen Marquard
Cc: mt at collab.sakaiproject.org; Sakai-Dev; Vijaykumar Sadupally
Subject: Re: [Building Sakai] distinct events for Resources and Dropbox (Sitestats)

If I recall correctly, events related to dropbox items will have an entity id starting with "/content/group-user/" and events for resources in regular resource collections will have an entity id starting with "/content/group/".

Jim

On Mar 23, 2012, at 8:32 AM, Stephen Marquard wrote:

> Files in Resources have a different reference structure to files in
> Dropbox, so I'm not really convinced it's necessary to have separate
> events.
>
> Regards
> Stephen
>
> Stephen Marquard, Acting Director
> Centre for Educational Technology, University of Cape Town
> http://www.cet.uct.ac.za
> Email/IM/XMPP: stephen.marquard at uct.ac.za
> Phone: +27-21-650-5037 Cell: +27-83-500-5290
>
>
>
>>>> Vijaykumar Sadupally <UdcsWeb at unisa.ac.za> 3/23/2012 2:21 PM >>>
> This message (and attachments) is subject to restrictions and a
> disclaimer. Please refer to http://www.unisa.ac.za/disclaimer for full
> details.
> ________________________________
>
> Good day David,
> I am Vijay from Unisa.
> We are experiencing a problem with Dropbox on Sitestats/statistics
> tool,there is no distinct event on Dropbox and resources. Both use
> content tool to generate their events.
> We need a way whereby each(Dropbox and Resource) will generate their
> own event separately.
> Currently the operations on Dropbox and Resources generates
> content.*events. It does not have a distinct events for Resources and
> Dropbox. Eg, content.* and dropbox.*
> This is reported in
> https://jira.sakaiproject.org/browse/SAK-11969
> https://jira.sakaiproject.org/browse/SAK-12336
>
> Jim Eng made the following comment in Jira:
> The problem seems to be that events are posted by the
> ContentHostingService, and CHS does not care whether the item is in a
> dropbox or resources collection, as long as permissions are satisfied.
> Ian suggested that the problem Jean-Francois described could be solved
> if the Resources tool posted events that distinguished dropbox events
> from resources events. For example, we might define two new sets of
> event-ids (e.g. "resource.read", "dropbox.read", "resource.new",
> "dropbox.new", etc) and when an event occurs within the resources tool
> or filepicker, the tool could post one of these events. CHS would still
> post a "content" event. You could then revise SiteStats so it watched
> the tool-specific events rather than (or in addition to) "content"
> events.
>
> I am going to start trying to make this change but would like to talk
> to the current owner of resource tool. I do not see the new owner after
> Nuno left Sakai. Could you please advice me on the new owner. Thank you
>
> Regards
> Vijay
>
>
>
>
> ###
>
> UNIVERSITY OF CAPE TOWN
>
> This e-mail is subject to the UCT ICT policies and e-mail disclaimer
> published on our website at
> http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from
> +27 21 650 9111. This e-mail is intended only for the person(s) to whom
> it is addressed. If the e-mail has reached you in error, please notify
> the author. If you are not the intended recipient of the e-mail you may
> not use, disclose, copy, redirect or print the content. If this e-mail
> is not related to the business of UCT it is sent by the sender in the
> sender's individual capacity.
>
> ###
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"