Forum OpenACS Q&A: Group composition and permissions hineritance

one
..two
....three

Unfortunately, contrary to my expectations, the acs_objects get as their context_id the object_id of the subsite and not that of the owning group.

Now I'm seeking the advice of those who know to make the program work as originally designed.

One possible way could be: when granting a privilege to a party also navigate the hierarchical structure and explicitly call acs_permission__grant_permission for all the dependent groups.

I wonder if there is a simpler way. I noticed that there are a couple of functions triggered by an acs_object update, i.e. acs_objects_update_tr and acs_objects_context_id_up_tr. Is it safe to update acs_objects pointing the context_id to the correct group_id to get the work done (i.e. automatically generating the acs_object_context_index)?

I would really appreciate any advice.

First, let me caution against modifying the permissions system.  It is a complicated beast fraught with possible performance killers unless you are able to do some serious profiling on your changes.

Don (and others) have spent a huge amount of time optimizing the system.

Let me see if I understand what you are trying to do:  You are modeling a hierarchical structure.  For your test you created groups "one", "two", and "three"  such that placing a party into group "three" essentially places him in groups "one" and "two" as well.

What I don't understand is what you are trying to achieve with permissions.  In the existing system, a permission is a triplet consisting of a privilege, an object, and a party.  So you grant a privilege ON an object TO a party.  That party can be a user or a group.  If you grant the privilege to the group, all members of the group get the privilege.  So, for example, if you granted "read" privilege to group "one", all members of group "three" would have the "read" privilege as well.
I'm thinking that you are suffering some of the same problems I had when wrapping my head around permissions.  Lots of stuff seems "backwards" (like group membership, OpenACS talks about components, so in your example you made group two a component of three and group one a component of two.  Most people would think of creating group one, then create a "subgroup" two and a "subsubgroup" three).  It often helps to think in terms of Venn diagrams and set theory when working with the groups system.

I think your statement above indicates a possible misunderstanding (maybe on my part 😊 ). Remember a permission is a *triplet* with one element of the triplet being an object for which the privilege would make sense.  Granting "write" to a party on a *group* has undefined semantics.  What would you be trying to achieve with that?

If you set the context_id of group B to be the object_id/group_id of group A, then in effect, group A is the parent of group B. Any objects that group B can access, group A should also be able to access. This is regardless of whether there is a composition relation between A and B.

What a composition relation will allow you to do is, for instance, you can add members to B (i.e. add a membership_rel of a party to group B), and they will also be members of A (They will have the same type of relationship to A).