Support custom group statuses

[Offereins]

Currently there does not seem to be any plan for a Group Status API, but the set of filters already in place to add custom group statuses, is incomplete. Most importantly, the list of statuses for the Privacy option on the Create Group or Edit Group screens cannot be changed dynamically.

Current extendable logic

I found the following filters to be present in bp-groups:

/bp-groups-admin.php
groups_allowed_status filter in bp_groups_admin_load()
bp_groups_list_table_get_views action in BP_Groups_List_Table::get_views(); only for adding views
bp_groups_admin_get_group_status filter in BP_Groups_List_Table::column_status()
/bp-groups-functions.php
groups_is_valid_status() checks component global valid_status; used only once in BuddyPress
/bp-groups-loader.php
groups_valid_status filter in BP_Groups_Component::setup_globals()
/bp-groups-screen.php
groups_allowed_status filter in groups_screen_group_admin_settings()
/bp-groups-template.php
bp_get_group_type filter in bp_get_group_type(); missing $group argument!

Current hardcoded logic

Within bp-groups the following locations contain hardcoded references to the various group statuses:

/bp-groups-actions.php
in groups_action_create_group() - new group status
/bp-groups-activity.php
in groups_record_activity() - hide_sitewide activity arg based on 'public' status
/bp-groups-admin.php
in BP_Groups_List_Table::get_views() - group views
in bp_groups_admin_edit_metabox_settings() - Privacy selector
/bp-groups-classes.php
in BP_Groups_Group::populate() - user_has_access prop based on status
in BP_Groups_Group::get() - there is no status arg in the groups query
in BP_Groups_Group::get_global_topic_count() - counts by status
in BP_Groups_Group::get_group_type_ids() - ids by status
/bp-groups-template.php
in bp_group_is_visible() - no filter
/bp-templates/bp-legacys
in groups/create.php: Privacy selector
in groups/single/admin.php: Privacy selector

Approach

In bp-groups-admin.php a @todo states that the group status label ​should be abstracted out somewhere for the whole Groups component. Perhaps we can try to move this, along with all other status details, into a single place and have all current filters and other non-filtered locations use the set of statuses as a reference.

Closely tied to the group statuses are group visibility and user access. In many cases the hidden status is hardcoded to be added to or removed from group (count) queries. Whether this should be looked into as well, I'm not sure.

Would this approach be worth the effort?

[dcavins]

I've also wondered if there was a clever way of building a filterable/extendable list of group statuses and their traits that could be referred to at action points. This would allow site admins to override some core group traits as well as add new group types--say if you wanted to make private groups invitation-only on your site. A very small example might be building something that looks like this:

group-types {
    public: [
        invites-allowed: true,
        request-membership: false,
        default-extension-access: 'anyone',
        default-extension-tab-visibility: 'anyone'
    ],
    private: [
        invites-allowed: true,
        request-membership: true, // this could be filtered to change the behavior
        default-extension-access: 'members',
        default-extension-tab-visibility: 'members'
    ],
    hidden: [
        invites-allowed: true,
        request-membership: false,
        default-extension-access: 'members',
        default-extension-tab-visibility: 'members'
    ]
}

Then there'd be some sort of helper that would be used to perform the various checks.
groups_get_group_trait( bp_get_group_status( $group ), 'request-membership' )

I think that @offereins and I are thinking along the same lines.

Also note that @imath wrestled with this complexity to create a restricted-membership public group:
​https://github.com/imath/altctrl-public-group

[boonebgorges]

Offereins - Thanks for the ticket. Related: #4119, #1125.

I agree that the current state of group statuses is an unholy mess, and I am 100% in support of cleaning it up.

I'm pretty sure I wrote the @todo you refer to, and my thinking is much along the lines of what dcavins has laid out above. Our group statuses are actually shorthand for bundles of related functionality:

Public: can be viewed in directories; can be joined by anyone without membership request; content can be viewed by anyone
Private: can be viewed in directories; can be joined by invitation; can be joined by membership request; content (aside from home page) is only visible to members
Private: cannot be viewed in directories; cannot be accessed by URL except if you are a member; can be joined by invitation; cannot be joined by membership request; content is not visible to non-members

Ideally, we would first abstract out all of these pieces of functionality (I think it breaks down to four or five different traits, plus perhaps some of the additional items dcavins has listed above - though I think those, strictly speaking, would be enhancements to the current setup). Each of the "traits" or "properties" or whatever would then be separately configurable, at least in code. Then, group 'status' would be internally parsed as shorthand for the bundles of properties listed above. (Think about, eg, what happens when you set 'public=true' in register_post_type().) Once this happens, we can have a central location for filtering the list of available group statuses - and maybe even introduce something like bp_register_group_status(), like the new bp_register_member_type().

This is all pretty complicated, and will have to be accompanied by copious unit tests, but it's a mountain we can climb! Let's see what we can do over the next few releases.

[boonebgorges]

See #6095, which is doing a bunch of the work I discuss in my previous comment (the "abstract out all of these pieces" bit).