Forum OpenACS Q&A: Groups and permissions

Posted by David Nind on 11/23/00 04:55 AM

I'm trying to get a handle on groups/permissions.

Example of what I am trying to do:

- I have the calendar module setup and working fine (as site wide
administrator I can post and edit calendar entries)

- I would like registered users to be able to post entries

- Would like for selected users to be able to administer the calendar
(not too concerned about being able to edit others entries)

My approach has been as follows:

So that only registered users can post entries I have put the
following in the appropriate post-new files:

if { $user_id == 0 } {
ns_returnredirect "/register/index.tcl?[export_url_scope_vars]
&return_url=[ns_urlencode [ns_conn url]]"
return
}

This seems to work okay.

To get users set up so they can access the admin pages:

- create a user group in Administration called Administration Group
for Calendar

- add users to this group that I want to administer the calendar

- put the following in the /calendar/admin/ pages
ad_sco

2: Response to Groups and permissions (response to 1)

Posted by Don Baccus on 11/23/00 01:38 PM

Your post was cut off, but you seem on the right track if you meant that you'd be screening visitors to the calendar admin page by membership in your admin group for calendars.

Permissions are a much more flexible approach if you need fine granularity of control over who gets to do what to which tables. It lets you grant arbitrary privileges to particular rows for various classes of user ("group", "group with role", "registered user", etc). The UI was built explicitly for the file storage module so only supports "read/write/comment/admin" privileges, but the datamodel and PL/SQL package allows any varchar as a priv name.

ACS 4.0 abandons user groups (which have lots of problems I won't get into) in favor of a more generalized grouping scheme, and uses the general permissions model to handle things rather than use a hodge-podge like ACS 3.*. In ACS 3.* the file storage module users permissions to grant admin perms to a user, but bboard uses a special bboard admin group, etc - it's a hodge-podge due to the evolutionary development of the module in response to aD's particular client needs during individual projects.

For ACS 4.0, a core technology team with no client responsibilities was formed, so they've been able to sit back and unify stuff.

This is one of many reasons we're so eager to start porting ACS 4.0 over to OpenACS.

3: Response to Groups and permissions (response to 1)

Posted by David Nind on 11/23/00 06:26 PM

I should have checked my post! It looks like ACS 4 will have major improvements - I'll help anyway I can, but am not a programmer by any means.

The last part of my message was:

To get users set up so they can access the admin pages:

- create a user group in Administration called Administration Group for Calendar

- add users to this group that I want to administer the calendar

- put the following in the /calendar/admin/ pages ad_scope_authorize $db $scope registered group_admin user

My problem is that any registered user can access the admin pages, so my question was if anyone can point me in the right direction to anything than can help me, it would be much appreciated.

I've checked the documentation, forums etc but still can't quite get my head around it.