[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
Comment:
> 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
directories?
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/>
BuddyPress
More information about the buddypress-trac
mailing list