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

[Jim Eng]

Hi Vijay,

In most cases where this has mattered to us, we just look at the value of the entity-id to determine whether it's a dropbox item or a resource item.  If that won't work for you, it's likely a code change would be needed.  I would suggest the following in that case:

Distinct events could be posted for dropbox items.  Make it configurable with the following possible choices:

1) just post "content.*" events for dropbox items (make this the default, since it is the current behavior)
2) post "content.*" and "dropbox.*" events for dropbox items
3) just post "dropbox.*" events for dropbox items 

Make that a property that is set in sakai.properties, and have it be a global setting within the CHS impl. Then whenever an event is posted, the code can check that value and post an event or events.

Jim


On Mar 26, 2012, at 7:36 AM, Vijaykumar Sadupally wrote:

> 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"
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20120326/6c4da5f2/attachment.html