[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