Forum OpenACS Q&A: Re: Group composition and permissions hineritance

Collapse
Posted by Tom Jackson on

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).

Collapse
Posted by Claudio Pasolini on
Thank you all for answering.

I'll try to better clarify the objectives of my application and why I used the groups system.

  • The program is a sort of project planning and control system.
  • Every project is owned by an organizational unit.
  • The organizational units are grouped in a hierarchy.
  • The projects are acs_objects whose context_id points to the owning org unit.
  • A user with write privileges on a group representing the org unit can manage all the corresponding projects.
  • Following the natural hierarchy, a user with a given privilege on a group should get the same privileges on all the groups (and the corresponding projects) down the hierarchy.
In the past I already developed an application implementing the hierarchy using the approach suggested by Dave, but this time I wanted to be smarter making use of the groups system.

Now I understand my error, but I'm searching a way to get the desired effect (make the component groups inherit the privileges of the composite, so as to enable a user to manage the corresponding projects) without too much disruption.

I think I will experiment pointing the context_id of the components groups to the corresponding composite, hoping that the triggers do the right work (they are too difficult for me to grasp) and then I'll tell you the results.