Define behavior for group status

[tandreatta]

In a project I needed to moderate join to 'public' groups.
I found some support for different group statuses, but behavior for 'public'/'private'/'hidden' groups is currently hardwired.
I needed also an 'archived' group type for groups not yet active.

With this patch I added the abiity to change (using filters):

• the allowed group types on creation/update [+].
• the group types who allow membership request.
• the group types who require membership requests approval.

[+] except super-admin.

[DJPaul]

Thanks for the patch, tandreatta. It's pretty involved and we are going to need to take some time to look at the patch and consider what it does before we can give you any feedback. I think there was another similar trac ticket recently about group statuses, so this might form part of that discussion -- I'll try to dig the ticket out later.

[imath]

The relative ticket DJPaul is talking about is #6094 (custom group stati)

@tandreatta fyi a while ago i've built this ​little plugin to "moderate" public group membership requests and do some other stuff

I think custom group stati could be interesting, but i also agree with boonebgorges's ​comment

[tandreatta]

New version of the patch - complete custom status management (listing/content visibility, membership moderation)

[tandreatta]

With the last sbmitted patch, custom status management is almost complete:

• custom status can be added with filter 'groups_valid_status' ($bp->groups->valid_status = array('public', 'private', 'hidden') );

• status who can be used in creation can be added/removed with filter 'groups_valid_creation_status' ( $bp->groups->valid_creation_status = array('public', 'private', 'hidden'); default creation status is the first defined status, but can be changed with filter 'groups_default_creation_status';

• filter 'groups_membership_request_allowed' defines the status who allow membership request ($bp->groups->membership_request_allowed_status = array('public', 'private') )

• filter 'groups_membership_request_moderated' defines the status who triggers membership request moderation ($bp->groups->membership_request_moderated_status = array('private') )

• filter 'groups_private_status' defines the status whose content is visibile only to members ( $bp->groups->private_status = array('private', 'hidden')

• filter 'groups_hidden_status' defines the status who is hidden in directory ( $bp->groups->hidden_status = array('hidden')

Group's description is automated (with functions group_membership_request_description( $status ), group_listing_visibility_description( $status ), and group_content_visibility_description( $status )). Adding/removing/changing behavior of a status will change description in Privacy section.

(Warning: since in my project I'm using a custom theme and users manage groups in the frontend only, backend and default theme are not yet heavily tested.)

[Warning 2: since my mother language is not English, may be I choosed some wrong function/variable names and/or descriptions.]

[boonebgorges]

This is really excellent - thanks for yor work so far, tandreatta. We can get started on implementing much of this right away after 2.2 comes out.

A few comments:

• I'd like to tweak function names in some places. My personal preference is to use the bp_groups prefix, despite the fact that many of our existing functions use just groups. And there are some functions that return boolean - like groups_private_group() - that should probably have a verb somewhere, like bp_groups_is_private_group(). (Maybe a bad example, because it seems odd to have the word 'private' in the function name - we should figure out a more proper descriptive name here.)
• We should add a function for fetching all valid group statuses, instead of reaching directly into $bp->groups->valid_status.
• Running status names through ucfirst() will not work as a general solution. This points to the need for a more robust method of registering custom group types. See #6006 for the member type API, and see #6094 for a closely related discussion.
• Related: stuff like BP_Groups_Component::valid_creation_status etc seems too ad hoc. If group types were stored in proper group type objects, then the objects themselves could have properties like 'show_in_creation' or 'requires_membership_moderation' or whatever. See ​https://buddypress.trac.wordpress.org/ticket/6094#comment:3

[tandreatta]

Replying to boonebgorges:

My personal preference is to use the bp_groups prefix

Mine too. But almost all functions in the bp-groups use just groups ...
In patch v2 boolean function names are groups_is_[private|hidden]_group_status().
I think that function should be use only internally - in next release I hope we will implement methods in BP_Groups_Group like $group->is_content_private(), $group->is_hidden_in_directory(), $group->is_membership_request_allowed(), etc..

We should add a function for fetching all valid group statuses

In v2 I defined groups_get_valid_status() and groups_get_allowed_status().

Running status names through ucfirst() will not work as a general solution.

But it works for defaults (public, private, hidden). And there are filters. And there is translation support.

This points to the need for a more robust method of registering custom group types.

But that method must allow translation.

Related: stuff like BP_Groups_Component::valid_creation_status etc seems too ad hoc. If group types were stored in proper group type objects, then the objects themselves could have properties [...]

I would prefer to have properties/methods in BP_Groups_Group instead.

[tandreatta]

Default theme works! Fixed an "use before set" error. Changed some function names.

[DJPaul]

But almost all functions in the bp-groups use just groups ...

Only because of legacy reasons. That's how the functions were built originally in the very first versions of BuddyPress. Some point later, we decided to use the "bp_" prefix on all (new) functions.

[boonebgorges]

I think that individual properties like this on BP_Groups_Group objects is a clunky approach. We should store these properties on the group type objects instead, and fetch them from there dynamically. I do like the idea of having BP_Groups_Group methods for getting the information, but we probably can't rely on this for a first pass, because we don't use real BP_Groups_Group objects everywhere. Notably, in a bp_has_groups() loop, the returned objects are *not* proper group objects. We can and should fix this, but it's probably a bigger task than is necessary to get the basic functionality in place here.

Running status names through ucfirst() will not work as a general solution.

But it works for defaults (public, private, hidden). And there are filters. And there is translation support.

Not all languages use ucfirst()-type capitalization in the way that we do. It won't be the case in all languages that the internal label will be a meaningful label. The internal keys for the group types should *not* be translatable - they're stored in the database, and should be persistent and reliably the same from the point of view of the code. Etc. But these are implementation details that can wait until we have a better sense of what we want the group type API to look like.