Forum OpenACS Q&A: membership_rel on a user

Collapse
Posted by Tom Jackson on

Using the user/groups/rels admin interface, you can only add relational segments to groups and users.

What I want to avoid is to add a new group for each user, as I want other users to be able to admin another user.

I thought I could do this by assigning a membership_rel between two users, using pl, or a new page for my application.

Can this be done? Are there any downsides to this idea?

Another option might be to just define a new relationship type.

Collapse
Posted by Tilmann Singer on
Could you try to describe a little more what you want to accomplish?

Which admin operations on a user do you want to be able to grant selectively?

I don't see what kind of sense a membership relation between two users would make - why should a user be a member of another user? Maybe you would rather want to grant explicit permissions on the user object, but these won't be reflected in the admin pages I am afraid, because they just check for subsite or site-wide admin.

Collapse
Posted by Don Baccus on
Is every user going to potentially administer any other user?  Sounds like some sort of touchy-feely woo-woo site to me, dude! :)

Off the top of my head custom pages to assign user master admin rights on user submissive directly would seem the simplest thing to do.

Groups and relsegs (subgroups in practice) really only make sense when there's structure to your communities as in .LRN (profs, staff etc within groups built for classes communities etc).  Doesn't sound like there's much structure here.

Collapse
Posted by Tom Jackson on

Looks like one side of the membership_rel is supposed to be a group, although I don't think it is enforced, so obviously this isn't the thing to do.

I have an application for cyclists, uni-cyclists actually. I'm thinking I want to have two group types: unicyclist and unicycle_club. And applicable to each group type would be the following: membership_rel (for the unicyclist), parent_rel and coach_rel.

Since a lot of unicyclists (being just kids) might not keep track of their own stuff, that might be done by parents or coaches, so I need a way to track those relationships. I'm guessing rel types is the way to do that.

Another problem is how to handle permissions on objects created by or for the unicyclist. I was considering the following: remove the two assigned permissions on the user, and add an admin permission for the user to the unicyclist group s/he is a member of. Then also set the context_id of the user to the unicyclist group_id. I haven't checked yet if this is going to work the way I want it to, but currently I assign permissions by setting the context_id of created objects to the user_id of the unicyclist. Setting the user's context_id to a group should pass the permissions up to the group, and therefore the ownership/control of all objects for that user.

If the context_id of the unicyclist group was set to a club group_id, then anyone with admin for the club group should be able to admin the unicyclist's objects as well.

The main point of all this is so that a coach could log on and list the kids he coaches, possibly add objects for them. Same for parents. Another possibility is to allow parents and coaches to log in and at least read what the unicyclist is writing, etc.

Collapse
Posted by Don Baccus on
This is very similar to the problem .LRN solves for clubs and various classes of members if I'm reading you properly, so you might look at the way they use groups and relsegs.

It's often easiest to make a relseg that mirrors the main group BTW.  I'd done that for subsites where membership_rel includes everyone in the group (you subtype new rels for new user classes/roles)  The cost of this duplication is light, you don't need new rows in the acs-rels table, just the relseg wrapper.  The nice thing about doing it this way is that you can grab any subset of users, including the subset that contains all group members, using the same Tcl calls, which makes it a bit easier to generalize stuff and to avoid special-casing ordinary members vs. admins etc.

Collapse
Posted by Tom Jackson on

Thanks Don, I was hoping my problem would sound familiar. I'll check out .LRN.