Geeklog Forums

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.

I have come accross a similar need and a couple years ago did a mod where you could make someone a restricted Group Admin. Extending on the idea, I'd like to see the following features:

• Site memeber could be assigned owner of a group - deletgated admin
  
• Users could be assigned to a primary group which lets us assign user admin to these delegated admins. This is great for larger site implementations. The main site admin would need to assign the primary group for new users - call it a delegated user pool.
  
• Delegated admins would have full user admin for their pool of users
  
• Delegated admins could create new groups but they need to be approved by the site admin
  
• Delegated admins could create sub-groups ok
  
• Delegated admins could assign/un-assign their pool of site members but site members outside their primary pool of users would need to be approved. This could be the main user admin or via an email invite to the user
  

---

Geeklog components by PortalParts -- www.portalparts.com

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:

• Add a new group type: user pool. A pool is a set of users and features. There are two levels of membership inside the pool: admin and member.
  
• Logged-in users become the master pool and only Group Admins can create additional pools. (Question: does this mean that we add a pool.edit feature or does it mean that when a pool is created we create a "group.$poolid.edit" feature and that becomes one of the pool's features?) Personally, I like the idea of
  
• pool admins can only create subpools through master admin approval
  
• pool admins can create groups under the pool and add users within the pool to the group as well as assign pool features to the group. (multiple nesting is allowed)
  
• groups can advertise their existence and allow users to request membership via a submission queue. If the group is in a pool, only pool members can see the group.
  
• pool admins can add users outside the pool to a group only with approval of someone higher up the pool tree.

  Example: there could be a pool called IT and within it two pools called IT Managers and IT Personnel. IT Managers might have a group called Budget Discussion. The IT Managers admin could request adding a normal IT Member into the Budget Discussion groups without adding him to the IT Manager pool with the approval of an IT admin. Likewise the global site admin could do this.

That is a cool balance of lockdown (user admin must do it) and openness (the user decides).