[buddypress-trac] [BuddyPress Trac] #6301: Group extension access settings disrespected by bp_core_new_subnav_item()

[buddypress-trac]

#6301: Group extension access settings disrespected by bp_core_new_subnav_item()
--------------------------------+------------------------------
 Reporter:  dcavins             |       Owner:
     Type:  defect (bug)        |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  Component - Groups  |     Version:
 Severity:  minor               |  Resolution:
 Keywords:  has-patch           |
--------------------------------+------------------------------
Description changed by dcavins:

Old description:

> In our new group extension access settings (see r8605), we've allowed
> users to independently set who can see the extension's navigation tab and
> who can visit the extension's display pane. However, because of a
> limitation in `bp_core_new_subnav_item()`, if who can visit the tab is
> more permissive than who can see the tab (for example, you create an
> extension that doesn't need a navigation tab, but does need to display
> the contents to anyone, like `'show_tab' => 'noone', 'access' =>
> 'anyone'`) `bp_core_subnav_item()` is never called. This prevents the
> navigation link from being created, but  it turns out that
> `bp_core_subnav_item()` must be called in order for the screen function
> to be caught. (See `bp_core_maybe_hook_new_subnav_screen_function()` in
> `bp-core-buddybar.php`.) And there's no way currently to call
> `bp_core_subnav_item()` without actually creating the navigation link.
>
> I've attached a patch (xx.01) that adds another argument,
> `user_can_see_nav_item`,  to `bp_core_new_subnav_item()` that controls
> whether the link is created in `bp_get_options_nav()`. `user_has_access`
> is still used to determine whether the screen function should be hooked
> or not.
>
> In patch xx.02, I used the new argument to call
> `bp_core_new_subnav_item()` if the user can see the nav tab or access the
> extension's display pane.
>
> I'm unfamiliar with the navigation creation functions, so would
> appreciate feedback.

New description:

 In our new group extension access settings (see r8605), we've allowed
 users to independently set who can see the extension's navigation tab and
 who can visit the extension's display pane. However, because of a
 limitation in `bp_core_new_subnav_item()`, if who can visit the tab is
 more permissive than who can see the tab (for example, you create an
 extension that doesn't need a navigation tab, but does need to display the
 contents to anyone, like `'show_tab' => 'noone', 'access' => 'anyone'`)
 `bp_core_subnav_item()` is never called. This prevents the navigation link
 from being created, but  it turns out that `bp_core_subnav_item()` must be
 called in order for the screen function to be caught. (See
 `bp_core_maybe_hook_new_subnav_screen_function()` in `bp-core-
 buddybar.php`.) And there's no way currently to call
 `bp_core_subnav_item()` without actually creating the navigation link.

 I've attached a patch (6301.01) that adds another argument,
 `user_can_see_nav_item`,  to `bp_core_new_subnav_item()` that controls
 whether the link is created in `bp_get_options_nav()`. `user_has_access`
 is still used to determine whether the screen function should be hooked or
 not.

 In patch 6301.02, I used the new argument to call
 `bp_core_new_subnav_item()` if the user can see the nav tab or access the
 extension's display pane.

 I'm unfamiliar with the navigation creation functions, so would appreciate
 feedback.

--

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