#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