[buddypress-trac] [BuddyPress Trac] #6285: Groups for specific member roles

[buddypress-trac]

#6285: Groups for specific member roles
--------------------------------+------------------------------
 Reporter:  sooskriszta         |       Owner:
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  Component - Groups  |     Version:
 Severity:  normal              |  Resolution:
 Keywords:                      |
--------------------------------+------------------------------

Comment (by boonebgorges):

 It seems to me that implementing this *alongside* the existing
 public/private/hidden spectrum might be a mistake. What does it mean, for
 example, to set your group to Hidden, but then to set "Display only to
 users of type 'Foo'"? If you are a Foo but not in the group, do you see it
 in directories? Member-type-specific visibility levels should probably be
 woven into the general group visibility schema somehow. See #6095 and
 #6094 for discussion of some foundational work that would have to happen
 to make group statuses abstract enough for this purpose.

 I'm also not convinced that the way you've carved the feature - for a
 given group, show it only to a whitelist of member types - is broad enough
 to warrant being implemented in a UI in BP core. It's quite specific.
 People will immediately want things like: member type membership forcing;
 limiting  membership requests by member type while leaving the group
 visible to all; allowing invitations to be sent only to a whitelist of
 member types; hiding groups from a blacklist of types (as opposed to
 showing them to a whitelist of types); and so on. All of these have valid
 use cases, but it's not obvious to me that any of them is going to have
 broader appeal in BP communities than any other. If we're going to move
 forward with native support for any of this sort of stuff, we should
 probably think more wholistically about it: how do group
 statuses/visibilities currently work; what is the reasonable range of
 visibility configurations we want to support; what is a reasonable range
 of possible ways for these configs to interact with member types; is there
 a logical way we can offer a system of settings that will make these
 configurations seem less like a bunch of checkboxes; etc.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6285#comment:6>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac