Gmane
Favicon
From: Glenn R. Golden <ggolden <at> umich.edu>
Subject: Re: Functions in group realms
Newsgroups: gmane.comp.cms.sakai.devel
Date: 2006-11-16 17:49:58 GMT (2 years, 32 weeks, 6 days, 7 hours and 12 minutes ago)
The current system is additive - any defaults would make it  
impossible to revoke a permission on a specific basis.  This is why ! 
site.helper is less than useful.

The query for permissions is a single query that lists a number of  
possible places where we might have the permission defined (i.e. as  
set of AuthzGroups).  It is a natural "and" situation.  Defaults that  
can be overridden (to take things away) at a specific level is more  
of an "or" situation; and would likely need to introduce a negative  
setting for permissions (i.e - check for a positive or negative  
setting specifically, and if that fails (here's the OR), check the  
wide default).

It would be a challenge to do this without killing the performance of  
authz, which would kill the performance of Sakai.

- Glenn

Glenn R. Golden
Software Architect, University Of Michigan
ggolden <at> umich.edu

On Nov 16, 2006, at 12:17 PM, Josh Holtzman wrote:

> Or even better, get rid of the authz templating system altogether  
> and replace it with a system-wide default + site/group-scoped  
> override mechanism.  This would significantly reduce the size of  
> the authz tables (since most sites don't override many -- if any --  
> of the defaults) and make changes to existing sites a snap.
>
> Josh
>
> John Leasia wrote:
>> Right -
>> There have been hallway discussions about creating a mechanism of  
>> updating existing sites - adding tools, permissions settings, etc.  
>> but nothing that I know of has started on that.  Maybe there is a  
>> REQ on it - I forget. It would be nice to be able to do what  
>> scripts are doing with respect to changing all realms or even  
>> adding tools to pre-existing sites via an admin tool for example.
>>
>> John
>>
>> Nuno Fernandes wrote:
>>
>>> John, thank you very much for answering!
>>>
>>> This leads me to the following conclusions when setting  
>>> permissions for new tools in EXISTING sites:
>>>
>>> a) If the tool needs SITE realms updated:
>>>    a.1) use !site.helper
>>>    a.2) OR use a script (eg, perl) - (at UFP we usually do this way)
>>>
>>> b) If the tool needs GROUP realms updated:
>>>    b.1) a script is the only option to do it
>>>
>>>
>>> Maybe I should create a JIRA for the creation of a !group.helper  
>>> realm?
>>>
>>> Thanks,
>>> Nuno
>>>
>>>
>>> Nuno
>>>
>>> John Leasia wrote:
>>>
>>>> Comments below -
>>>> John
>>>>
>>>> Nuno Fernandes wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> For a core sakai tool (and perhaps, for provisional tools),  
>>>>> default site permissions are already set on !site.template.*  
>>>>> realms and default group permissions on !group.template.*  
>>>>> realms. So, every new site and group will come with the correct  
>>>>> default tool permissions. Existing sites/groups will have their  
>>>>> permissions updated by running an appropriate db script by the  
>>>>> time the tool is added to sakai core.
>>>>> As an example, "content.read" from Resources is part of both  
>>>>> templates for the access and Student roles.
>>>>>
>>>>> I have some questions about permissions in group realms for non- 
>>>>> core sakai tools:
>>>>>
>>>>> a) On a sakai tool, one could provide a permission page in  
>>>>> order to set permissions for the different roles. This  
>>>>> procedure, I believe, should set permissions ONLY for the site  
>>>>> realm as one could desire having custom permissions per group.  
>>>>> Is that correct?
>>>>>
>>>> jl> Yes that's right.
>>>>
>>>>> b) We can override realm permissions ONLY for sites, by editing  
>>>>> the !site.helper realm. Is that correct?
>>>>>
>>>> jl> Yes that's correct. Note that overriding a permission via ! 
>>>> site.helper has the affect that the permission cannot then be  
>>>> unchecked in the corresponding tool's permission page in sites.
>>>>
>>>>> c) Supposing b) is correct, shouldn't sakai have an equivalent  
>>>>> for groups? (!group.helper)
>>>>
>>>>
>>>>
>>>> jl> That would probably be nice to have.
>>>>
>>>>>
>>>>> d) Supposing a) and b) are correct, how can one set permissions  
>>>>> (for a new non-sakai tool) on existing groups without manually  
>>>>> editing each group realm? Is a db script the only way?
>>>>
>>>>
>>>> jl> People have been using scripts to do this. Here at UM, we  
>>>> have used !site.helper when something new comes along, say  
>>>> during the term, while also setting it properly in the templates  
>>>> for new sites. Then after a term or two as older sites drop off,  
>>>> we remove the setting from !site.helper so as to avoid the  
>>>> problem mentioned in b).
>>>>
>>>>>
>>>>>
>>>>> Thank you for your attention,
>>>>> Nuno.
>>>>>
>>>>>
>>>>
>>>
>>
>> ----------------------
>> This automatic notification message was sent by Sakai Collab  
>> (https://collab.sakaiproject.org/portal) from the DG: Development  
>> (a.k.a. sakai-dev) site.
>> You can modify how you receive notifications at My Workspace >  
>> Preferences.
>>
>
> -- 
> Josh Holtzman
> Educational Technology Services, UC Berkeley
> jholtzman <at> berkeley.edu
> 510.529.9225
>
> ----------------------
> This automatic notification message was sent by Sakai Collab  
> (https://collab.sakaiproject.org/portal) from the DG: Development  
> (a.k.a. sakai-dev) site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.
>

[see attachment: "message0.html", size: 15791 bytes]

Attachments:

message0.html
https://collab.sakaiproject.org/access/content/attachment/b174ad6b-6601-4fd5-00f7-9d9547e1665e/message0.html

----------------------
This automatic notification message was sent by Sakai Collab
(https://collab.sakaiproject.org/portal) from the DG: Development (a.k.a. sakai-dev) site.
You can modify how you receive notifications at My Workspace > Preferences.