[Building Sakai] Membership of copied site

[Branden Visser]

Zhen Qian wrote:
> 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?

I think more flexibility in automating how a user's site is created is a 
great idea. We have a custom site request tool to handle the automation 
of prepping sites for instructors, and our admin also performs quite a 
few manual operations to ensure that prepping a site each semester is as 
hands-off as possible for the instructor.

I don't think we've never seen a need to do anything along the lines of 
what you describe as "deep copy". In addition to using "Duplicate Site" 
in Site Info, we see a need for "Use a site as a template", which I 
think you described as "customised copy".

Another idea we've been kicking around is "Tool Packages" (Kind of like 
a static site template). Rather than providing users a list of site 
templates to use, we would just have preset groups of tools that provide 
certain classes of functionality (e.g., assessment, peer communication, 
content-sharing...). They could pick several of them, depending on what 
functionality they will be offering for the semester.

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