[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    |
-------------------------+------------------

Comment (by boonebgorges):

 imath - Many thanks for having a close look at the patch. 4785.08.patch
 has some revisions.

 > 2/ Testing the different group extensions in bp4785.php, everything
 seems to work as expected as soon as the group is private. If the group is
 public and trying to access to BP4785_Ext4 for instance, i'm redirected to
 the login.php file even if i'm already loggedin, it's then an endless
 redirection to login.php

 Ah. I'd only been testing with logged-out users. At its root, the problem
 is with `bp_core_no_access()`, which has default redirect arguments
 related to wp-login.php. I've chosen to handle this in a more modular way
 than you've suggested: I pass the `$no_access_args` to the
 `'bp_group_user_has_access'` filter, and then modify them in the callback
 (see the new `BP_Group_Extension::group_access_protection()`). I think
 there is actually a more fundamental problem with `bp_core_no_access()`
 here (it should have its own failsafes against this kind of thing); I'll
 open a separate ticket and bring it to the attention of r-a-y.

 >  3/ I might be wrong, but i think in
 BP_Group_Extension->user_can_see_nav_item() the check should be done on
 the $this->params['show_tab'] and in BP_Group_Extension->user_can_visit()
 the check should be done on $this->params['access']

 Yes. Good catch.

 > 1/ After applying the patch, i'm redirected to '', if testing on a
 MAMP/WAMP dev environnement i'm arriving on the localhost root. Else the
 user should land on the site's front page i guess.

 This looks like a very ugly problem, and your proposed solution is very
 ugly too :) It's amazing to me that we're only now discovering this
 problem, given that we've used `bp_core_new_subnav_item()` for
 `BP_Group_Extension` forever. Can you give details on how to reproduce
 your problem? I think we need to take a deeper look at the root cause
 instead of writing fixes that are too specific.

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