[buddypress-trac] [BuddyPress] #3961: Need hierarchical groups

buddypress-trac at lists.automattic.com buddypress-trac at lists.automattic.com
Fri Jan 27 00:42:14 UTC 2012

#3961: Need hierarchical groups
 Reporter:  sooskriszta               |       Owner:
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  Future Release
Component:  Core                      |     Version:  1.5.3
 Severity:  major                     |  Resolution:
 Keywords:  dev-feedback 2nd-opinion  |
Changes (by boonebgorges):

 * cc: ddean (added)
 * keywords:   => dev-feedback 2nd-opinion
 * milestone:  Awaiting Review => Future Release


 > Not having hierarchical groups in BuddyPress core is like if
 hierarchical pages were not part of WordPress core…

 That's a bit extreme. Hierarchical groups would be useful for some
 implementations of BuddyPress, but it's not obvious that it's
 overwhelmingly required for most instances.

 From the data schema point of view, hierarchical easy - just allow for a
 parent_id or something like that. But there are a ton of questions to be
 asked about what this means for users. Member propagation is one question,
 as you've addressed above. But what else would the parent-child
 relationship mean for groups? Would aspects of the groups be merged
 (forums, activity, etc)? Would each group have a display of its child and
 parent groups, perhaps in the header? Would this require additional
 filters on group directories, or possible tree-like views of group

 Again, the technical issues here are (mostly) not that difficult. But it's
 only worth adding the feature(s) if it can be done in a way that is clear
 to all users, and that proves useful to most.

 In any case, I have a couple of alternate suggestions to bundling all of
 this with BP:

 1) Build proper group taxonomy and meta support. If BP had built-in
 support for group categories and/or tags, it would solve a big part of the
 impetus behind group hierarchy (that is, explaining that certain groups
 are related to each other). IMO, group taxonomy is of much broader appeal
 than standalone hierarchy, and it's clearer (to me at least) how it would
 be implemented from a UX point of view. If this were done, then it would
 be pretty easy to build a plugin that does the additional work of, eg,
 propagating group membership among similarly categorized groups.

 2) Build better support for ddean's BP Group Hierarchy plugin
 http://wordpress.org/extend/plugins/bp-group-hierarchy/ into BP core
 (ddean - I added you as a CC to this ticket - hope that's not too rude :)
 ). This plugin is popular and highly regarded, but I think that David has
 run into a couple of problems with implementation that have led to some
 less-than-ideal situations. For one, his plugin has to modify BP's groups
 table to add a parent_id column; we might consider doing this in BP
 itself. He's also built his own version of bp_has_groups() just so that he
 can add hierarchy support, and he does some clever tricks to mess with
 BP_Groups_Template. If we add a parent_id column to our db schema, we
 could also add hierarchy support (parent_id, and maybe others if it's
 relevant) to the bp_has_groups() stack of functions. Then we let the
 plugin provide all the necessary UI elements, like it already does.

 In the short term, I lean toward the latter. It's something we can do
 fairly easily, it'll make ddean's life much easier, and it won't affect BP
 users who aren't interested in group hierarchy. Long term, we could then
 talk as a team about how/whether to implement some of the user-facing
 stuff in BP in future versions.

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/3961#comment:1>
BuddyPress <http://buddypress.org/>

More information about the buddypress-trac mailing list