[buddypress-trac] [BuddyPress Trac] #6677: Groups: Draft, Locked or Suspended status

[buddypress-trac]

#6677: Groups: Draft, Locked or Suspended status
------------------------------------+-----------------------------
 Reporter:  dcavins                 |       Owner:
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  Future Release
Component:  Groups                  |     Version:  2.6.1.1
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+-----------------------------
Changes (by dcavins):

 * keywords:   => has-patch dev-feedback
 * version:  2.3.3 => 2.6.1.1


Comment:

 Here's my first draft of an approach to adding more flexible group
 statuses and adding finer-grained control over group capabilities. This
 approach allows developers to filter the common group statuses, add
 completely new statuses, and check group capabilities. This is sort of a
 simplification of WP's user role capability system applied to groups.

 == Ways to filter group statuses: ==
 === Filter one of the default statuses (applies to all groups with that
 status): ===
 {{{
 add_filter( 'bp_groups_public_group_status_caps',
 'my_edit_public_group_status_filter' );
 function my_edit_public_group_status_filter( $caps ) {
     // Members must request to join public groups and be approved.
     $caps['join_method'] = 'accepts_membership_requests';
     return $caps;
 }
 }}}

 === Add a completely new status (or remove an existing status): ===
 {{{
 add_action( 'bp_groups_register_group_statuses',
 'my_register_group_status' );
 function my_register_group_status() {
     // A generally public group with moderated membership.
     bp_groups_register_group_status( 'sprivate', array(
         'display_name'    => 'Semi Private',
         'capabilities'    => array( 'join_method' =>
 'accepts_membership_requests' ),
         'fallback_status' => 'public',
         'priority'        => 20,
     ) );
     // Make a group visible only to site admins.
     bp_groups_register_group_status( 'suspended', array(
         'display_name'    => 'Suspended',
         'capabilities'    => array( 'show_group' => 'noone',
 'access_group' => 'noone', ),
         'fallback_status' => 'hidden',
         'priority'        => 95,
     ) );
     // Remove the stock "hidden" status (this would be a bad idea in the
 short term).
     bp_groups_deregister_group_status( 'hidden' );
 }
 }}}

 === Filter the capabilities for a particular group (or based on some group
 characteristic): ===
 {{{
 add_filter( 'bp_groups_group_object_set_caps', 'my_edit_group_no_2_caps',
 10, 2 );
 function my_edit_group_no_2_caps( $caps, $partial_group_object ) {
     // Members must request to join the group with the id of 2.
     if ( 2 == $partial_group_object->id ) {
         $caps['join_method'] = 'accepts_membership_requests';
     }
     return $caps;
 }
 }}}

 === Check the capability for a particular group by passing the group
 object into the following function: ===
 `$who_can_access = bp_groups_group_has_cap( $group, 'access_group' );`

 == Caveats: ==
 === Custom statuses or very changed statuses will cause unexpected
 behavior in plugins that are checking the status for the three basic
 statuses: public, private, or hidden. ===
 We'd need to get group-related plugins updated like this:
 For instance, code that decided whether to create a public activity post
 like this:
 {{{
 if ( 'public' === $group->status ) {
     # do the thing
 }
 }}}
 might become
 {{{
 if ( version_compare( bp_get_version(), '2.7', '>=' ) ) {
     if ( 'anyone' != bp_groups_group_has_cap( $group, 'access_group' ) ) {
         # do the thing
     }
 } else {
     if ( 'public' === $group->status ) {
         # do the thing
     }
 }
 }}}

 === Orphaned custom statuses will also produce unexpected results.===
 It would be easy enough to build a status migration tool for the BP tools
 screen that displays unregistered group statuses and asks the site admin
 which status to migrate those groups to. But, this could be kind of
 awkward. We could also store a group's capabilities as a groupmeta item,
 but that has the disadvantage of requiring meta lookups. (Then the issue
 could be the group's status and the stored capability meta could get out
 of sync.)

 To provide more granular visibility and access, I’ve added a potentially
 expensive routine `get_hidden_group_ids()` in `BP_Groups_Group` and
 `BP_Groups_Members`. The results are cached, but I’ll have to test this on
 a site with many users and groups to see if it’s viable.

 === Other changes: ===
 I added two new parameters to the BP_Groups_Group object: `is_visible` and
 `user_has_access` which reflect the current user's relationship to the
 group.

 Because of the caveats, I'm not entirely sold on this approach, but I'm
 putting it forward so we can figure out how to improve on it or do
 something smarter.

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