Relational segments are perfect for describing subsets of users in situations such as Tils mentions. They're lighter weight than a group.
You just define a new relationship type, say "employee", then add an "employees" relational segment to the group with rel_type "employee".
You can then use the relational segment to admin perms for that subset of the group en masse. Think of relational segments as a way of assigning a role to a subset of a group.
There are two major problems with this rosy picture:
1. The group UI stuff lets you add relations and add users to groups in the role defined by that relation, but doesn't actually create a relational segment. Darn :( That means you want to use groups as Tils describes if you're creating these from the UI rather than code, because without the relational segment there's no way to say "give all people with the admin_rel relationship to my group 'admin' privs".
2. The only way to build a subgroup of a group currently is with the "composition_rel" type. This says "Group P(arent) consists of all members assigned directly to P UNION all members of Group C(hild)".
If you create a relational segment named (say) "admin" in both the P and C group, then add someone to the "admin" relseg for C, they're propagated upwards into the "P" groups as an admin.
Oops. Looks like relsegs weren't quite thought out all the way (they are marked "experimental")
I'm investigating the creation of a real "subgroup_rel" relation that will say "Members of C must already be members of P" rather than combine the two. Subsites already enforce this notion so composition isn't really what is wanted anyway, and it would fix the aforementioned bug regarding the propagation of membership-in-role upwards.
Creating the subgroup_rel stuff is easy, it's the upgrade script that's nasty.
composition_rel and relational segments don't play nice together Sigh ...
