Forum OpenACS Development: Inheriting or Aggregating an "Administrative Group"?

Collapse
1: Inheriting or Aggregating an "Administrative Group"?
Posted by Frank Bergmann on 01/17/04 12:38 PM
Hi,

We've started porting a small subset of the ACS 3.4 Intranet to OACS 5.0.rc1. On thursday Pol Vilarmau and I had some fruitful discussions about OO, templates, permissions, ... I think we've got a reasonable plan now how to proceed. We're going to publish "po-core" for public comment as soon as it produces any types of results...

One important remaining doubt is with respect to "administrative groups". In ACS 3.4 Intranet, every business object (project, customer, office, partner, ...) has an "administrative group" (identical with its primary key: create table im_projects ( project_id references user_groups, [...]). Basically, the "members" of the administrative groups get read access to the biz object, and administrators of the admin group can write to the object.

I OACS 5.x this would mean inheriting from "groups", which sounds a bit strange to me ("project" is a subtype of "group"....). However, replacing this inheritance relationship by an "aggregation" (for example introducing a field "admin_group" in po_projects) would make porting quite a bit more complicated...

Any ideas?

The current code is available at http://www.project-open.com/po-core-0.1d.tgz

Bests,
Frank

Collapse
2: Re: Inheriting or Aggregating an "Administrative Group"? (response to 1)
Posted by Don Baccus on 01/17/04 10:40 PM
Well ... to be honest that was strange in the ACS 3.4 Intranet, too, a real kludge and misuse ... one we probably don't want to mimic in your port, as you point out.

You don't need to add fields like "admin_group" to po_projects, though, you can query directly for "which groups have admin access to this particular po_project object" if you decide to go the group route.