Subgroups for Organic Groups Rewrite

+1 ...

This is something that would be very useful in several areas... geographies as noted and many educational settings like terms and classes, etc.

--
Blog: Adding Understanding | Drupal Developer Search | Drupal Services: Brauer Ranch

Sometimes users wish to have content in a subgroup behave as if it had been posted to the parent group. That way, someone could subscribe to California and stay up to date on everything happening in the state, for example.

I should be clear that from an og perspective there would be no such thing as a subgroup. They are flat. The hierarchy that collects a bunch of group nodes into 'California' can be taxonomy or menu, as stated. Then it is Views that makes the aggregated listing for 'California' based on California's children.

We'll need some UI clarity here too. A few use cases would help I think.

We have not discussed how email notification and membership works. I guess those are out of scope.

In my job, we've created more than 10 organic groups based sites over the last year. I was involved in the information architecture of a good part of them. Some had hundreds of groups, some had 10s of groups, some had tens of thousands of users, some had hundreds. We had a wide variety of use cases: groups for siloing a web site into sections, groups for giving member organizations and their campaigns a space on a common hub, topic groups for discussions etc. We even had one use case with geographical groups: regions + countries + local chapters.

I can tell you: subgroups are bad design. In most cases.

• Signing up people to other groups that they're not immediately signing up to is not intuitive.
• It is assuming a decision on behalf of the user .
• It opens complex issues with notifications,
• It makes your site more complex which will have repercussions when you want to move on to another system in 2 years (what's the current typical life time of a web site?)

I didn't want to bring this up from the get go, because I assume that there are good use cases for this feature (see my comment above). But for me this is the core problem of the proposal - sub groups seem to be at most a corner case.

So, for improving the proposal, from my point of view, it will be crucial to come up with a compelling user story why sub groups are needed and a concept of how to implement them cleanly.

... if i completely got what you are talking about:

my project has to deal with about 80 local chapters in 35+ countries.
at the moment, we use a tuned up old forum system without a role system, that provides those groups with a basic group page for news and a shout box for internal chatting and communication in their mother language.

but those shoutboxes are too crappy to lead real discussions or preparing projects, so i thought about giving all groups a restricted forum, where they can discuss their matters in their mother language (on the rest of the site english is mandatory) without flooding the hole site with babylonic language mixes.
but that would be a maintenance nightmare in that system, so i thought about converting to drupal (THE community system ;) )

the second finding was, that the collaboration of chapters within one country is not really supported by the site structure, so setting up a national level as a parent group above the local chapters would be a good idea as well.
members of local chapters automatically become members of that national parent group and have access to the national forum + those items from other subgroups, users classified as important for the national level.

how else then by using subgroups can i sort members and restrict access the way i want to have it? how can taxonomy help me there?
the only solution besides those subgroups would then be to set up 80 roles and give them access to each group forum manually?. pfuhh!

indeed, the organic groups and subgroups are flat and even after a year of searching and asking, i found no way to make it treelike.

but actually, thats the way REAL communities (and organisations) look alike. we are not that much interested in playing around with galleries and youtubevideoaudioflashgarbage for everyone, but in structured and productive communication without disturbing the rest of the community.

so, where are those propagated intranet features i read about so often?
... can´t find them.

i´m still not 100% sure if i hit the point of discussion, so please forgive me if i did not.
i think there are more ppl who would need a system as i described. if you know a site using drupal with the existing tools who managed to set up sth like this, please tell me which. but i start to doubt that such sites do exist.

I described a number of use cases in the issue here: http://drupal.org/node/228493

In short, I'd like to see subgroups support the propogation of posts AND users. Using a simplistic example, think of football teams, you might want a private (parent) group of the football coaches, who are the group (football team groups) admins who are propogated up. The normal group members are the footballers and should not have access to the "coaches" parent group.

There are all sorts of variations on this.

I'm working on a political action website and I'm wondering if our needs are a suitable use case for subgroups.

We have dozens of active volunteers and staff supported by hundreds of casual volunteers. For a particular task (eg, voter outreach), we have several different sectors (students, community organizations, regional organizers, etc) - ie, candidates for subgroups (voter outreach parent group, specialized subgroups). The reason for having a parent group is that there are many issues common across all subgroups - outreach materials, messaging advice, etc - that we would like to post in one place for all to have access to.

We would like members of any subgroup to automatically be a member of the parent group - with our current flat structure, we have to register people in both the subgroup (or subgroups if they belong to more than one) and the common group. This is an administrative problem as sometimes the person doing the registration forgets to register the person in the common group.

Given the discussion in this thread, is this use case a justification for using subgroups, or should I tackle it using a taxonomy-based approach?

Another wrinkle is that the most active volunteers are sometimes discussing more strategic issues and hence want to keep their communications private. I understand that one can create group-specific roles, but I'm not entirely clear how to limit the visibility of forums or book pages to only those group members with a particular role. Any pointers would be most welcome.

I looked into subgroups to allow groups to feature/showcase specialized nodes within their groups, and I think the concept has potential. As I have used it however, it seems to miss a few key features which I think would lock in a solid UI and powerful functionality.

The current group interface provides methods for group members to add nodes to their group, but no way to logically promote/feature certain nodes, or their created group pages. I think subgroups could provide a fix to this problem if implemented properly, which from reading here I am unsure if its possible with the way subgroups is built, but here goes.

I'll outline the problem more specifically here:

Lets say you have a group, say, "5 star restaurant," and it writes blogs on recipes. Let's say it has blogs for normal recipes, but it wants to feature blogs for "Holiday Recipes" on its OG group page. Featuring specific nodes on a group page isn't possible with OG out of the box, but with some views magic and either the flag module or the nodequeue module (with subqueues for OG enabled), you can create views that can be "featured" if the flag or the subqueue is updated/selected. This is a clever fix but it doesn't address the fundamental problem: that groups are unable to create and logically associate nodes within their groups by specific context. I'm aware of the group taxonomy module and I have it enabled, and groups can create their own taxonomy, but as far as I know views doesn't provide a solid (global) way to assign group nodes to a group (or group section) based on group-specific taxonomy. Views allows the creation ad-hoc views for a singular organic group using that groups specific taxonomy, but there's no way to filter nodes by saying: Post in current group, and (a theoretical) filter saying: Taxonomy: Taxonomy term in current group, or something along those lines (for all groups site wide). Even that filter would be inadequate, as if a group had 10 different custom taxonomies within their group it still wouldn't provide the necessary tools to split up each node into its specific taxonomy grouping. Moreover, creating ad-hoc views per group is fine if you have 3 groups, but if you have 500 groups your life is going to be miserable.

Moreover, if a group wished to create a new page dedicated to showcasing blogs involving holiday recipes, they could do that with the og_panels interface, but once they create a new page, even IF a view was made that somehow managed to capture the specific taxonomy for each group on the site and display only posts tagged with that specific taxonomy, the new group pages (through og_panels) don't appear on the front page except with tabs. Tabs might work great for webmasters and developers, but from a UI perspective they're incredibly unfriendly - especially if you're using a top navigation menu schema. Users will not find that UI friendly or simple in any capacity, nor would they consider it intuitive. If they can't navigate to the page or if it isn't prominent then the functionality is useless.

I currently know of no way to create a view that says show all "group pages" (pages created with og panels) in current group. Even if there was, there's no fields to attach on for customized display.

IMHO, these above problems could be solved by a robust subgroup interface. Here is how I envision an ideal system:

The OG Subgroup module would add a node type called "subgroup." A group can add a subgroup to their group in the exact same fashion that a group can add a blog to their group. When viewing the subgroup, they can add whatever content they would like through the same UI as on the parent group (OG content type admin module could restrict content types available to be posted into a particular subgroup) and the created content would propagate the subgroup. Options on the subgroup interface would allow the content to appear in the parent group and/or the subgroup itself based on the group administrators preference. This is all that is needed to set the stage for a really powerful engine because views and flag/nodequeue provides the rest:

A view could be created to say "Node type: subgroup, and posts in current group" to create a block on the group homepage that links to all the subgroups, and a simple cck text field with numbers ranging from -10 - 10 would add a weight feature which allowed users to determine which groups came up first and which ones were at the bottom. 10 extra minutes of work by the site webmaster would provide a flag/nodequeue method to feature a subgroup in a yet a seperate block if they wished.

With that set, viola! You have subgroups that have a fixed and clean layout (running it through panels with NID arguments), a simple and powerful way for group admins to compartmentalize information as they see fit, a logical way to feature the subgroups (and content therein, as the option could be set to propagate the subgroup only), and an ability to showcase it on the front page of the group so the tabs interface is bypassed and its clearly prominent to the user.

Thoughts?

I'm using the current 5x beta.

My goal is to allow group members to create subgroups within their group exactly like they add nodes to their group, and their associativity is the same, only the nodes they are adding would function like groups.

So subgroups would be a "group node" and a "standard group post." So if Group A creates a subgroup, call it subgroup A-1, they can add nodes to that subgroup exactly like they would be able to add nodes to the parent group. The nodes added to subgroup A-1 would be assigned to that subgroup just like a node is assigned to an organic group. Ideally, there would be an option to select either on the node edit/creation form or the subgroup edit/creation form whether content propagates to the parent group or not.

After trying a while to get og_subgroups working (which has been problematic as currently no user but user 1 can see the "create subgroup" link even though they have the appropriate permissions), creating a subgroup does not allow (as far as I can tell) to add nodes to that new subgroup as if it was a parent organic group. Nodes still post to the parent group.

I assumed this was how OG subgroups was designed.

If I'm mistaken and its not how it was designed, I can move this to the support queue.

And I also am (sucessfully) using smartqueue for organic groups.

I was wondering what hierarchy technique (maybe taxonomy like in the D4.7 version, or a table like in D5, or node hierarchy, or the menu system, or nodereference, etc.) had been implemented in the new 6.x-1.x-dev version of the Subgroups for Organic groups module. Of course, there are different opinions on which is the best way. So, I've looked into recent code commits.

The new maintainer has said: "Right now its basically a port from D5". Indeed, in these commits, the D6 book dependency is removed, and only the og dependency remains (see og_subgroups.info). And, instead of using taxonomy, or the Node Hierarchy module, etc., there are now subgroups with their own hierarchy.

That is, og_subgroups.install includes a schema definition of a og_subgroups table with two fields: gid (integer, the ID for a group) and parent (integer, the gid of the parent group). Also, there are new functions for propagation of content and members, etc. So, this is it, and thank you very much to Bschilt, the new maintainer.

Recently, Amitaibu wrote: "Subgroups are possible in OG7, but in order to propagate content/ users OG_subgroups7 should be used (In time of writing OG_subgroups7 doesn't exist yet)."

That's great news. Does anyone know what subgroup technique is OG7 using? Maybe taxonomy, one that Moshe Weitzman (OG) seemed to prefer a couple of years ago? Will it be reasonably easy to upgrade group hierarchies from og_subgroups6 to OG7?

I know this post is very old, but I learned some things from it, even though alot is over my head, and I thought maybe you would like to see a beginners perspective, on what decisions an enthusiastic, non programmer, beginner might struggle with while trying to figure out if, or how, they can make subgroups on their site. Please see my full post here ….

https://www.drupal.org/node/2314555

Synopsis:
In short, I am looking for a means for any user to come to my site, and create and manage a group, which is about their subgroups, which they also create and manage under their top group.

In the subgroups they will have various content types and content, and members, which the manager/creator the can manage, and also some content and content types I will manage globally.

It should be easy for them. And, it should not involve me as site master having to do much, actually preferably anything, for them to do this, on their level, other than just routine maintenance. Or at least as little as possible.

I have studied a number of possibilities from Sugroups to OG+taxonomies(I guess) (I suppose just taxonomies is possible) to CiviCRM, and others but there are issues and questions I don’t have the experience to find answers for. See the full version for these issues and questions. I don’t really have coding skills to build modules by the way. What is the right direction? I appreciate it. Thanks.

This is a side suggestion from a beginner's perspective for whoever wants to know. I would like to see comparisons tables for Drupal issues like these which might have several solutions, so beginners can make reasonable choices, with say with a Beginner to Advanced scale on top and then various methods or choices like mine listed on the left with pro and con issues and alternatives to consider in the middle. It would sure make it easier and faster for beginners to get through the learning curve, than to have to read through so many posts and guides. There are so many choice possibilities, some relevant and some not, that it seems logical to have a way to help guide people through them. Thanks.