[Building Sakai] Membership of copied site

[Zhen Qian]

Branden:

I agree. It is a kernel change.

And I think ideally we should have different choices for copying  
sites, e.g. deep copy (exact duplication, including all attributes  
and properties, even bring over added site members) or customized  
copy (only basic site attributes, the tool list (with or without tool  
content), no provider ids, etc)

Ideas?

Thanks,

- Zhen

On Sep 23, 2009, at 9:41 AM, Branden Visser wrote:

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