[Building Sakai] Membership of copied site

Branden Visser branden at uwindsor.ca
Wed Sep 23 06:41:19 PDT 2009


Zhen Qian wrote:
> There is a separate group created for course site for each associated 
> provider id. I think the problem was introduced by the deep copying of 
> site groups when copying site (SiteService.addSite())
> 
> So even there is an attempt to clean the new site realm after the site 
> is copied inside SiteAction.java, DropboxContentObserver is already 
> observing those users from the copied provider group and hence created 
> dropbox folders during the SiteService.addSite() process.
> 
> SAK-12860 cleans the target realm for provider id, but it doesn't solve 
> this dropbox issue. I will reopen this ticket.
> 

Unless I'm missing something, just adding:

realm.setProviderGroupId(null);

into SiteService.addSite() is solving the DropBox issue and the 
potential privacy issue. SAK-12860 just needs to be relocated to 
SiteService because it's an API bug, not a Site Info bug.

Thanks,
Branden

> Thanks,
> 
> - Zhen
> On Sep 23, 2009, at 9:12 AM, Branden Visser wrote:
> 
>> We're on 2.5.2. I'm using the SiteService.addSite method directly to 
>> copy a site, that must by why we're seeing this issue, since the fix was 
>> tossed into SiteAction.
>>
>> Shouldn't this fix be right in SiteService.addSite instead, so that the 
>> API isn't exposing this potential privacy issue? If there are no 
>> objections, I can re-open the ticket and attach a new patch.
>>
>> Thanks,
>> Branden
>>
>> John Leasia wrote:
>>> Hi Branden,
>>> Right, duplicating a site shouldn't carry over the provider id.
>>> http://jira.sakaiproject.org/browse/SAK-12860
>>> I forgot which version you are at - if you still see the problem in a 
>>> fixed version please reopen the Jira.
>>>
>>> thanks,
>>> John
>>>
>>> Branden Visser wrote:
>>>> Hi everyone,
>>>>
>>>> Sometimes when we copy a site using SiteService.addSite(String, Site), 
>>>> if the source site has dropbox installed, dropboxes for all the 
>>>> users on 
>>>> the source site get created as well. This is not desired, since the new 
>>>> site will definitely have a new roster.
>>>>
>>>> I've narrowed this problem down to the fact that the copy process does 
>>>> not clear the new realm's provider id, so if it still provides users 
>>>> then the DropboxContextObserver generates folders for those users.
>>>>
>>>> It appears as though the site-copying process does attempt to purge the 
>>>> new realm's membership, so it smells like a bug. Should this be 
>>>> clearing 
>>>> the provider as well?
>>>>
>>>> Best,
>>>> Branden
>>>> _______________________________________________
>>>> sakai-dev mailing list
>>>> sakai-dev at collab.sakaiproject.org 
>>>> <mailto: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 
>>>> <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a 
>>>> subject of "unsubscribe"
>>>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org 
>> <mailto: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 
>> <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a subject 
>> of "unsubscribe"
>>
>>
> 


More information about the sakai-dev mailing list