[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 needs-unit-tests  |
----------------------------------------+------------------

Comment (by boonebgorges):

 In r8538 I've started writing unit tests that codify the way things
 currently work.

 In a public group, `visibility` does nothing, because everyone has access
 to it. `enable_nav_item` can still be used to toggle the nav item.

 In a non-public group, setting `visibility` to `private` will cause the
 nav item not to be created for users who do not have access to the group
 (ie non-members).

 Here's the tricky case: In a non-public group, setting `visibility` to
 `public` allows the setting of `enable_nav_item` to be respected. That is,
 `visibility=public` and `enable_nav_item=true` leads to the creation of a
 nav item (in `buddypress()->bp_options_nav`, even for users without access
 to the group. However, clicking on this nav item will lead (via
 `BP_Groups_Component::setup_globals()` to a redirect to wp-login.php. I
 guess the use case here is when you want to show that the subtab exists,
 so that people can click and then have the login redirect logic (ie, the
 content of the tab is private, but the existence of the tab is not).

 Gotta run for now, but hopefully this is a starting point in getting
 backward compatibility stuff straightened out.

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