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.
