Groups for specific member roles

[sooskriszta]

Now that we have a functioning ​API, perhaps it may be a good idea to allow Admin to specify (many to many) relationships between Groups and Member Roles. So, certain groups could be for certain types of members, e.g. Moderators. In a sense it is an extension of the "Hidden" group functionality, just much more powerful.

[boonebgorges]

Can you say more about what this would do? Would it make certain groups invisible to certain member types? Would it force group membership? How does one build a UI for such a thing?

[sooskriszta]

I don't think you meant to remove my subscription to this ticket. So have added it back.

Would it make certain groups invisible to certain member types?

Exactly.

Would it force group membership?

No. There might be a usecase for this, but perhaps more suitable for a plugin.

How does one build a UI for such a thing?

I was thinking of a very simple UI. By default all groups are for all user roles.
On the Edit Group page there could be a box with checkboxes for User Roles (somewhat like WordPress lists Categories in case of Pages or Posts). After #6161 is implemented, this should be among bulk edits as well.
If no user roles have been selected for a group then the group is for all user roles, i.e. all selected = none selected.

[boonebgorges]

I don't think you meant to remove my subscription to this ticket. So have added it back.

Correct - we edited over the top of each other, and I couldn't see how to add you back. My apologies.

I'm not totally clear on the general use case for this feature. I can see specific scenarios where it could be useful, of course. Can you say a bit more, in broad terms, about how you imagine that you'd use this feature on your own BP sites?

[sooskriszta]

One example, say company BigBadWolf uses BuddyPress for its Intranet.

It has several user roles, along the lines of its departments
e.g. FrontLine Sales, Marketing, BackEnd Developers, FrontEnd Developers, Legal, Managers, etc.

Now while some departments' (read groups') activity could be public, there would be some groups that would want to limit access. e.g.
RedRidingHood Litigation Group may want to be visible only to Legal and Managers, etc.

[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.

[espellcaste]

I agree with @boonebgorges, the functionality outlined seems best served as a plugin.

[sooskriszta]

Replying to boonebgorges:

It seems to me that implementing this *alongside* the existing public/private/hidden spectrum might be a mistake.

I was just thinking of this as an *extension* of the public/private/hidden model.

[DJPaul]

Re-reading this now, I agree with Boone, but it's definitely a use case we should consider being able to support as work on group/member permissions in the future. Thanks for sharing your idea, sooskriszta!