[buddypress-trac] [BuddyPress Trac] #4785: Decouple "visibility" and "access" properties

[buddypress-trac]

#4785: Decouple "visibility" and "access" properties
-------------------------+------------------
 Reporter:  smninja      |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  2.1
Component:  Groups       |     Version:  1.7
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |
-------------------------+------------------
Changes (by boonebgorges):

 * keywords:  has-patch needs-unit-tests => has-patch


Comment:

 4785.04.patch is a first pass at fixing this API. High-level overview:

 - Group access control has been moved out of `BP_Groups_Component` and
 into a separate function `bp_groups_group_access_protection()`. Running it
 late means that `BP_Group_Extension` plugins (and other plugins as well)
 can modify the default logic. (Separate idea: it'd be cool if BP's own
 subpages - like 'request-membership' - were registered using
 `BP_Group_Extension`. But at least for now, access to core pages can be
 customized with the 'bp_group_user_has_access' filter.)
 - Deprecate the `visibility` and `enable_nav_item` params for
 `BP_Group_Extension`. In their place, introduce `access` (who is able to
 visit the tab) and `show_tab` (who is able to *see* the tab). Each param
 takes the following possible values: 'anyone', 'loggedin', 'member',
 'mod', 'admin', 'noone', or any combination thereof in an array. Backward
 compatibility for `visibility` and `enable_nav_item` is provided. See the
 attached plugin bp4785.php for some examples, but in brief, the logic
 works like this:

 {{{
 // No 'access' or 'show_tab' defined:
 //   - In public groups, tabs are fully publick
 //   - In non-public groups, tabs and their content are members-only
 // For most plugins, this will probably be the desired setup, so it's the
 default.
 parent::init( array(
     'name' => 'Foo',
     'slug' => 'foo',
 ) );

 // 'Access' set but 'show_tab' not set.
 // 'show_tab' defaults to the value of 'access'
 parent::init( array(
     'name' => 'Foo',
     'slug' => 'foo',
     'access' => 'member',
 ) );

 // In some cases, you may want to show the tab to all users but limit
 access to the tab to members
 // When a non-member clicks on the tab, she'll go to a wp-login.php
 redirect
 parent::init( array(
     'name' => 'Foo',
     'slug' => 'foo',
     'access' => 'member',
     'show_tab' => 'anyone',
 ) );

 }}}

 Backward compatibility is a bit tricky because the `visibility` and
 `enable_nav_item` features are implemented in such an inconsistent and
 confusing way. But, in essence, they translate like this:

 {{{
 // 1. This
 'enable_nav_item' => true,
 'visibility' => 'public',

 // becomes this for public groups
 'access' => 'anyone',
 'show_tab' => 'anyone',

 // and this for private groups
 'access' => 'members',
 'show_tab' => 'anyone', // this is a quirk of the current implementation

 // 2. This
 'enable_nav_item' => true,
 'visibility' => 'private',

 // becomes for public groups
 'access' => 'anyone',
 'show_tab' => 'anyone', // another quirk of the current implementation

 // and for private groups
 'access' => 'members',
 'show_tab' => 'members',
 }}}

 Users who want more sophisticated logic can override the
 `user_can_visit()` and `user_can_see_nav_item()` methods in their
 `BP_Group_Extension` implementations. See BP4785_Ext6 in the attached
 plugin.

 Summary: I think that the 'access' + 'show_tab' API is much clearer and
 much more flexible than the old one. And between the attached unit tests
 and the sample plugin, I think I've done about as much as possible to
 ensure backward compatibility. Looking forward to feedback and thoughts
 from other devs.

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