This is from a discussion about permissions on OpenACS' irc (names changed) that took place sometime circa 2005.
ryan: How do I create a group containing other groups?
ryan: For instance, I have 30 admin groups, and instead of adding user A to each one manually, I want to add her to one group, and thus all 30.
dave: what are you trying to accomplish?
dave: you can't do that
dave: it it totally non-intuitive
dave: here is why :)
dave: we have the Super Admin group
dave: no it doesn't work
ryan: So what is a composition_rel? I thought parties were supposed to be a superset of groups.
dave: let me explian :)
ryan: ok, thanks :)
dave: here is how it works.
dave: Super Admin
dave: then we have admins_a which is a component of super admins
dave: maybe it can work.
dave: question is
dave: can a group
dave: have a composition_rel to more than one other group
ryan: So what is the definition of a component?
dave: lets find out.
dave: a component
dave: so if Admin A is a component of Super Admin
dave: then every meber of A is a member of Super
dave: which is NOT what you want.
dave: you want ever member of super to have permission over all the groups "inside" it right?
dave: but in this case every member of A would have permission over all the other components etc.
dave: group are NOT for permissions.
dave: that is the design weirdness
ryan: Now I am completely confused.
dave: you can't use groups the way you want
ryan: isn't the whole point of groups to avoid permissioning on individual users?
jim: but you should be able to build a page that asks for a user and puts the user into the 30 groups
dave: ryan, yes.
dave: you they don't inherit the way you think
ryan: so you set permissions on a group with a set of objects, then just add/remove users from the group, right?
dave: its backwards to what you are thinking.
dave: that works
jim: so you can get what you want (convenience, non-tedium) but have to do it another way
dave: but composition_rels
dave: behave backwards
dave: they are not useful for org chart models
ryan: ah ok.
dave: but I think it can work
ryan: WHat is an application of composition_rels?
dave: here is what you would do
dave: if it works
dave: create all your groups
dave: Admin A, Admin B etc
dave: then make one group
dave: and give it a composititon rel to all of those groups.
dave: its upside down.
dave: then if I am in the one group, i am in all of those other groups
jim: so you're putting the one group into all the groups
jim: that should work :)
dave: b/c its not _in_
dave: its a component.
dave: i think that will trigger the correct permissions.
ryan: how do components work in the data model - I want to understand this better.
dave: then I recommend you 1) read the acs-kenrel sql files
jim: s a special kind of acs_rel
dave: 2) run alot fo experiments in psql
dave: 3) find a bug in the triggers
dave: that is how I figured it out.
dave: sucks huh.
dave: seriously the comments in the SQL files in acs-kernel are very illuminating.
dave: also have you read permissions tediously explained?
ryan: but you're it'll work?
dave: i am not sure it'll work
jim: we think it will work
ryan: but I could re-read it a fourth time
dave: i don't see any rule
dave: that disallows a group being a component of more than one group
dave: if there is such a rule, it won't work.
ryan: but compositions typically extend 'up' the chain of groups?
dave: that is what its for
dave: so for example
ryan: what is a practical example?
dave: I have Main Subsite
dave: and several other subsites
dave: actually this is an example of why it doesn't work :)
dave: hmmm actually I have to check
dave: not sure if susbsite groups are components of main subsite or not.
ryan: You see, I want to create this super group and then let the client admin the members...
dave: ok there are no rel_contraints on a default install. so that should be safe.
dave: but its really a sub-group
jim: try it with two groups and another group be a componenet of both groups... give each of the first two groups two different permissions... put a user into the component group...
dave: a super group would not work the way you want.
dave: here i what you do
jim: see if the user has both perms
dave: 1) create two groups
dave: 2) create another group
dave: 3) make the thired group a compoennt of the first two
dave: 4) add someone to the third group
dave: 5) check if they are a member of 1 and 2
dave: for extra credit
dave: apply a permission to 1 and 2
dave: check if the members of 3 have permission on those things
dave: if this works
jim: 1-4 and the extra credit are what I just sed :)
dave: i just solved the oldest OpenACS 4 riddle
joe: As a topical aside, we changed the way we use groups in our subsites for dotcommunity. One for admins and one for members (so we don't use admin_rels). Then we use a composition rel to make admins of top level sites also admins of lower level sites, and to compisitions in the opposite direction to make members of lower level sites members of the higher level ones too.
dave: jim, yes :)
jim: 5 is a good idea too
ryan: ok, sounds good. Will test and get back to you. That would be very cool if it could work both ways. Obviously it is important to be able to have groups of groups...
dave: joie: you could still use admin_rels to do that
dave: it would work the same way.
dave: ryan, yes if that works the way I expect it would be cool.
dave: joie, so is the lower level admin group a component of the higher level admin group?
joe: The problem with admin rels was that an admin of a subsite became an admin of the supersite, which isnt what we wanted.
dave: or the othe way around?
dave: joie: yes
dave: that is what I just said
dave: the component rels go the wrong way
dave: than what you would think intuitively
dave: although mathematically they work correctylu as specified.
dave: damn PhDs
dave: basically we need to write high-level functional wrappers over all this crap
joe: So we have a compisition rel going "down" for admins, and "up" for members. So the supersite admin group is a component of the subsite's admin group, and the subsite's members group is a component of the supersites members group.
dave: so you can just call a tcl proc that tells you what happens (instead of what is does in the database)
dave: joie: ah so it _does_ work. that is just what I told ryan-g to do
dave: we need to write a tcl api to do that that is clear what is happening.
jim: so members of the subsite become also members of the supersite
dave: which makes sense
joe: Indeed. Then we frigged the acs-subsite members pages to do the "right thing".
dave: but then admins of the subsite become admins of the supersite (if you use admin_rels)
dave: which is why you don't want to do that.
dave: joie: but you are right
dave: and openacs is wrong
dave: except I doubht there is an upgrade script that would work
dave: damn PhDs
dave: joie: why the hell didn't you tell us this before? :)
dave: i have been trying to figure that out for 4 years
joe: We have an upgrade script that does it somewhere. Rob wrote it.
dave: you rock.
joe: We weren't sure the new way was "right".
dave: it is
dave: b/c it makes sense
dave: no its right.
joe: We then got rid of admin_rels completely.
joe: and only use membership_rels
dave: b/c everyone expects it to work that way
dave: yeah see
dave: the problems is
dave: all this stuff was experimental
dave: and noone every finished it
jim: you would need to be careful when deleting certain objects
dave: except you did.
dave: so now we can say "this is the way its supposed to work' We can say that because that is the way everone has expected it to work, but it never did
jim: make sure to remove all rels first then delete
dave: i am so surprised.
joe: The code is in the dotCommiunity download on www.dotcommunity.org. The upgrade scripts aren't there though.
dave: this is so cool.
dave: get them!
joe: Heh. I'll talk to Rob about it tomorrow, as not sure what he implemented.