Forum OpenACS Development: Using groups, acs_rels, and relational segments

1: Using groups, acs_rels, and relational segments

Posted by Dave Bauer on 01/30/03 07:53 PM

Does anyone have any experience using the groups system they would like to share?

So far, i have been able to get some information from the dotLRN data model about how they might be used. I am working on a document that shows examples, and I was wondering if there are any other working systems that use these features.

2: Re: Using groups, acs_rels, and relational segments (response to 1)

Posted by Don Baccus on 01/30/03 08:14 PM

Check out the Tcl lib in subsites for a bunch of utilities. acs-subsite barely makes use of them but the work was never completed. One of my goals for 4.7 is to finish this up.

A "relational segment" is just a subset of a group. It was a bolt-on to the existing 4.x groups structure. A very useful one. I just mention this because if one were to start from scratch one could probably solve the groups and subsets of groups problem in a more elegant way. relsegs work, though, and are fairly easy to work with.

acs_rels is just a generalized object-to-object map (somewhat overblown, IMO, but we can live with it). In the context of groups and relational segments there are two predefined relation types for groups: membership_rel ("this person is a member of group foo") and composition_rel ("the members of group foo also belong to group bar").

A relational segment builds a subset of a group by referring to a relationship type that describes the subset (say "professor_rel") then inserting rows that read something like "User scotttiger, group foo, professor_rel").

Querying the acs_rels table for "group foo/professor_rel" will return the set of professers in group foo.

Querying the acs_rels table for "user scotttiger, professor_rel" will return all the groups that scotttiger is a professor of.

Etc etc etc

Does this help?

3: Re: Using groups, acs_rels, and relational segments (response to 1)

Posted by Tilmann Singer on 02/06/03 10:30 AM

I think the purpose of group-types is often misunderstood, e.g. when you have a simple intranet site and want to give certain privileges to a few users such as employees and customers, I've often seen people create a group-type 'employees' and then create a single group of this type 'Employees', while it would have been totally sufficient to create it as the default group-type 'group'.

Creating new group-types only makes sense when you want to define extra attributes with the groups of this type.

This misunderstanding is caused by the confuing UI I guess.

4: Re: Using groups, acs_rels, and relational segments (response to 1)

Posted by Dave Bauer on 02/06/03 04:45 PM

Luckily I haven't touched the UI. I just used the pl/sql apis.

What I did was create group-types because each different kind of group I am usig is going to be an object-type anyway. So i figured that using the group-type object-type was the best solution in that case as opposed to linking my object_type specific table to the group through a group_id column. Also this application will have multiple groups of each group type.

5: Re: Using groups, acs_rels, and relational segments (response to 1)

Posted by Don Baccus on 02/06/03 06:35 PM

Relational segments are perfect for describing subsets of users in situations such as Tils mentions. They're lighter weight than a group.

You just define a new relationship type, say "employee", then add an "employees" relational segment to the group with rel_type "employee".

You can then use the relational segment to admin perms for that subset of the group en masse. Think of relational segments as a way of assigning a role to a subset of a group.

There are two major problems with this rosy picture:

1. The group UI stuff lets you add relations and add users to groups in the role defined by that relation, but doesn't actually create a relational segment. Darn :( That means you want to use groups as Tils describes if you're creating these from the UI rather than code, because without the relational segment there's no way to say "give all people with the admin_rel relationship to my group 'admin' privs".

2. The only way to build a subgroup of a group currently is with the "composition_rel" type. This says "Group P(arent) consists of all members assigned directly to P UNION all members of Group C(hild)".

If you create a relational segment named (say) "admin" in both the P and C group, then add someone to the "admin" relseg for C, they're propagated upwards into the "P" groups as an admin.

Oops. Looks like relsegs weren't quite thought out all the way (they are marked "experimental")

I'm investigating the creation of a real "subgroup_rel" relation that will say "Members of C must already be members of P" rather than combine the two. Subsites already enforce this notion so composition isn't really what is wanted anyway, and it would fix the aforementioned bug regarding the propagation of membership-in-role upwards.

Creating the subgroup_rel stuff is easy, it's the upgrade script that's nasty.

composition_rel and relational segments don't play nice together Sigh ...