Forum OpenACS Development: rel-segments and compositions revisited

Dear all,

More or less since ever, OpenACS has a problem in the interplay between permission management, composition of groups (via composition-rels) and relational segments (automatically managed groups). Background:

Relational segments are parties (groups of users), which are automatically maintained to collect members with certain relationships to a group. Such relationships are e.g. the admin-rel or a membership-rel, the corresponding relational segments are e.g. "members of group1" or "admins of group1".

Since a relational segment for the admin relation contains all administrators (and a relational segment for members contains all members, etc.), the party_id of relational segments are often used for assigning permissions (e.g. give all admins of a group certain permissions).

Compositional rels allow the definition of groups with subgroups in a way, such that members of a subgroup become automatically members of a parent group. The used mechanism uses the relational-segments to insert users to all relational segments along the compositional path that are defined for matching relations types. This way, the relational segment for the membership-rel of the topmost group of a composition path contains all members of all subgroups.

<h3>The problem:</h3>
The process of collecting members with certain relationships in the relational segments is transitive over the composition-rels: when a user is member of a subgroup, the user is as well member of the parent group. This is as intended and perfectly fine. However, the problem is that this happens as well for admin-rels: when a user is admin of a subgroup, the user is added to the relational segment of admins of the parent groups. In essence, this means, when compositional-rels are used, all admins of small communities become automatically admins of the supergroups (e.g. the whole subsite), which renders the construct useless for permission management. One can find comments about the at various places in the forums

https://openacs.org/forums/message-view?message_id=111185
https://openacs.org/forums/message-view?message_id=111235

The problem intensifies when subsites are used. The subsite admin-pages of a site/subsite show only the groups of this subsite (e.g. of groups used in a composition-rel with the site/subsite). When e.g. dotlrn is used, these admin pages don't show the groups/communities of dotlrn, since dotlrn communities don't use compositional-rels (most likely for the reason above). This is one of the reasons, why dotlrn is not subsite aware.

<h3>The problem visualized:</h3>

The following graph shows a small site with a user "gn" (494), the predefined groups ("the public" and "registered users") and a sample group "app-gr1" (818). In addition, there is a relational segment for the members of registered users (684) and a relational segment for the "admins of registered users" (685). When user gn (494) is added as admin of app-gr1 (admin rel 829), the user becomes automatically member of the relations segment of the parent group, "admins of Registered users" (685) and as well member of (684). Under the graph is a listing of the party_approved_member_map, where the membership in 685 is marked as red as well.

So, adding a admin relation for app-gr1 has the consequence that the user became a member of the admins of the registered users. One might argue, that this is not ok (because the admin-rel was originally set on 818), but on the other hand, the permissions are currently always set on parties, and in party_approved_member_map, there is no party for administrators of 818. So, when the red tuple would not be inserted, the fact that user 694 is an admin of 919 would not be not reflected in party_approved_member map. so the behavior can be regarded as correct.

However, let us consider the following case, where we have added a relational segment (1185) for admin-rels to app-gr1. When the user 694 is added newly as an admin to 818, this is reflected by the admin-relation 1188:

The admin relation 1188 causes user 694 to be member of 1185 (admins of 818) and of 685 (admins of -2). In some respect, this is true, when the relational segments are meant to express "in this group or any of this components, user 694 is an admin", but this interpretation is not compatible, if one wants to add permissions to the rel-segments of just the container group, which an admin of the component group should not have.

<h3>A possible solution:</h3>

Therefore, a possible remedy is to avoid that the transitive adding of tuples in such cases (the boxed tuple above). This can be achieved in multiple ways. In the tip of Michael Steigman [1] relationships can be defined as "composable" or not, meaning that the transitive adding to supergroups along the composition path can be avoided. Another approach would be, to mark relational segments as transitive or not. Since Michael Steigman has provided oracle-code and test-cases, i am leaning towards his approach, and i have added an updated version of his patch the my current working instance.

The experiences are quite good. By setting the admin relationship non-transitive, compositional rels can be used in dotlrn without harm, and the groups/memberships can be made instrospectable via the subsite admin group management pages. Per default, all relations are composable (aggregating along the composition path), so there is no harm for existing OpenACS/dotlrn sites (since these use composition rels seldomly). The changes makes composite rels applicable in much more cases (e.g. all classes of a certain master program, etc,) and it brings dotlrn closer to plain openacs principles.

Are there comments/objections? I am planning to add the patch to the forthcoming OpenACS 5.9.1 release.

[1] https://openacs.org/forums/message-view?message_id=4031049