Subgroups for Elgg


I'm looking for information and feedback on subgroups for elgg. 

I need a subgroups module for a project I am working on. I have cast about looking for information on subgroups for elgg. I have found a variety of groups extension modules - subgroups, related groups, extended groups, etc. None fit my application need. 

In my application the primary requirements are:

1. A subgroup is a group within a group (it is "contained" by the group).

2. Its members are a subset of the containing groups membership.

Secondary requirements are:

1. Group tools (pages and  widgets) are subgroup aware (meaning they know about and can display content from subgroups as well as the containing ).

I've found a subgroup plugin (lorea I think). It allows attaching a group to a group. However, it does not have membership controls nor any work to change group tool behavior. 

I've begun coding and would love to get community feedback as I go. Thoughts?


  • @Brian Chapin I too have been after this for years... not a coder alas, so stuck.  I am using the lorea subgroups and related groups at the moment, but woulsd like to have them linked by a heirachy of information flow, so that a national governing body can send updates etc to its regional subgroups and then the local groups can receive the info too. or  I am interested in  any other options you are thinking of too.

  • This could be a somewhat heavy coding task ;-)

  • I was thinking about membership controls... if a group can only make a subgroup, or a subgroups can only request to become a subgroup, then surely membership is covered?

    I am not sure about members being being a subset, as in some of my instances, people are members of a national organisation but practice locally, and in otherspeople are members of related groups and members of more than one regional or national body... so things can cet unneccerily complex.

    I am also not bothered about tools etc.  If there are rss widgets and feeds available, content from any group can be dispayed as desired by the groups.

  • @Brian - handling membership should be fairly easy. Making the tools (files, forum discussions, pages, etc) subgroup aware is the hard part. Right now, an object is group aware by setting the container on the object to the group GUID. There can be only one container. This means an object (like a file) can be in either the super group or the sub group with the current code.

    You could

    1. rewrite the code to use relationships to define what is in a subgroup or supergroup. This would then allow you to put an object in both groups.
    2. you could have the super group code be aware of all of its subgroups. When the latest group blogs are displayed, it doesn't just query the database based on the group's container but also includes the subgroup containers in the query.
  • A few more things to consider:

    Can an item's access be limited to a single group? When you're looking at SF (San Francisco), do all CA (California) items show up, or only if their access is set to public/logged in users? What if SF doesn't want to see certain CA or national items in their group?

    Can any groups within the tree be closed? If Courtney asks to join CA, then she must also join US and WO (World). Which of the three group owners decides to accept her, or must they all accept her? Must she always join the root group (WO) first and work her way down?

    When someone creates an object in CA, can (s)he limit access to: entire group tree, CA + US, CA + US + WO, CA + all child groups (cities), CA + all descendant groups, etc.?

  • Ignoring the difficulty of coding for a moment, I think it would be far more flexible to have a more robust subscription model:

    Each group/user already has a public channel (its "public" items), but imagine if it could create additional public and "premium" channels. Any user/group could subscribe to any public channel, but would have to request access for premium channel content.

    That would allow each group to subscribe to exactly the content they want while retaining autonomy over its members and content. And each user would retain control over the groups with which (s)he wished to be associated.

  • Just finished discussing with Zak and created subdomain to demo "SuperGroups"
    Sometime in the next day or so I will install Elgg 1.7.3 and enable SuperGroups for those interested in such features..

    is alive for anyone who wants to check out Zak's SuperGroups..
    Questions ? Just ask.. You might need some hand-holding at first....