Inspired by Dazzy's post....
I'm curious how much interest there would be in Lightweight Groups. Currently, to make a group you need to be a Group Admin and that allows you to assign feature rights to various groups. This is not something you want to give to just anyone.
A Lightweight Group would be restricted: a) it would not possess features and b) it could not contain other groups. What's it good for? Well, with those restrictions you can let anyone create a group any time they want. And that means any object in the system with standard permissions could be assigned to a random group of users. The forum's Buddy List could become a real group for example.
Other Features:
- User groups would appear on user menu as "my groups"
- Groups would have permissions so "my groups" could be public or private giving GL abilities similar phpBB.
- Integrated with standard GL permissions
I had more but I can't find my notes... I'll post again when I find them.
That's actually even more than I wanted but it would also work. I was actually thinking about my implementation and gl_groups would end up having added fields of 'owner_id', perm_owner, perm_group, perm_member and perm_anon with perm defaults of 3, 2, 0, 0. Meaning only owner can add members and users not in the group don't see it. You could unhide the group with a 2 in perm_member and/or perm_anon. And you could make a 'friendly' group where anyone can add members with a 3 in perm_member. Or the membership list could be locked by setting perm_owner to 2. The group could even be hidden from the members with perm_group = 0.
With your delegates idea, perhaps the list of perms becomes perm_owner, perm_member, perm_group_pool, perm_nonpool. Then visibility inside and outside the pool of users is controlled by perm_group_pool and perm_nonpool and perm_member means actual member of the group not the members of Logged In Users.
In my original idea, grp_gl_core become grp_type where 0 is a normal group, 1 is a core group and 2 is a feature-less group. Although perhaps user pools also need a type. Also, with the pool concept, the feature problem perhaps is less important as the pool assigned to the group delegate would also have a set of features. This list of features may or may not belong to the delegate but it is the only set of features he could assign to groups in his pool.
Let's see:
This could be the main user admin or via an email invite to the user
That is a cool balance of lockdown (user admin must do it) and openness (the user decides).