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