Extend Buddypress Group Forums Capabilities

[aaclayton]

Buddypress group members are temporarily granted the capability to read and publish in their own hidden group forums using the function map_topic_meta_caps() in /includes/extend/buddypress/group.php line 179.

This function only runs if the following conditions hold:

if ( ! bp_is_single_item() || ! bp_is_groups_component() || ! bp_is_current_action( 'forum' ) || ! bp_is_action_variable( 0, 'topic' ) )

This results in some circumstances in which a group member doesn't have adequate capability to participate in group forums whenever the action variable is not 'topic'. For example, when using a group forums template with a new topic form below the topics-loop, regular group members will lack the capabilities to create a topic.

Is it necessary to require that the action_variable be 'topic' in order to grant permissions? I think switching group member capabilities would be useful everywhere within the bp_is_current_action( 'forum' ) sub-component.

Unless I'm missing a key reason not to do this, I would recommend conditioning the capability switch only on:

if ( ! bp_is_single_item() || ! bp_is_groups_component() || ! bp_is_current_action( 'forum' ) )

[aaclayton]

Was just revisiting my ticket, and I noticed it should say: "This (capability switching) function only runs if the conditional logic does NOT hold."

I've experimented with my proposed change and haven't noticed any negative side effects. I would maintain that perhaps a slightly less strict conditioning logic would be appropriate here.

[aaclayton]

I discovered another really bizarre issue while continuing to investigate my problems with group member permissions.

This function map_topic_meta_caps() runs over 100 times when loading my group forums!?!?!? I'm not sure what's going on yet, maybe I'll figure something out.

[johnjamesjacoby]

Address the recursive map_topic_meta_caps() issue

[johnjamesjacoby]

(In [4716]) Map group forum meta caps directly to 'bbp_map_meta_caps' filter to avoid recursion. Also remove BuddyPress 'topic' action check, to allow single group-forum capability map to work correctly. Fixes #2140.

[johnjamesjacoby]

(In [4717]) Supplemental removal of group forum capability mapping after group forum is displayed. See #2140.

[johnjamesjacoby]

This function map_topic_meta_caps() runs over 100 times when loading my group forums!?!?!? I'm not sure what's going on yet, maybe I'll figure something out.

If the limit you're running into is this:

Fatal error: Maximum function nesting level of '100' reached, aborting''

It can be raised by increasing: xdebug.max_nesting_level in your php.ini.

PHP itself doesn't have a limit on the depth of the stack, so you should only encounter this with WP_DEBUG set or xdebug enabled.

[johnjamesjacoby]

Moving this to future release.

I'm not confident on how to duplicate the issue anymore. On a typical vanilla installation, this seems to work as anticipated.

It's possible the user accounts that are experiencing issues maybe don't have the correct user capabilities? Anyhow, without a sure fire idea of what's going on, and it not being a regression, let's look at this in 2.4 or in a 2.3.x release.

[aaclayton]

OK, I wanted to revisit this topic and update it with some information that I have figured out. To briefly re-summarize the issue:

• My site has many private groups. If these groups have forums, they should be hidden from non-group members. In order to achieve this, the logical step is to set the group forum to "hidden" in the admin panel.

• The map_topic_meta_caps() function is intended to automatically grant group members/mods/admins appropriate capabilities within group forums.

• This capability remapping fails to allow group members to create new topics within hidden group forums.

I've done some further investigation here, and have a hypothesis as to what is causing this issue. When a new topic is posted, I think bbp_new_topic_handler() is running before the capability remapping completes.

I think this might be because the capability remapping uses functions like bp_group_is_member() which rely on the $groups_template global. HOWEVER, the $groups_template global is not populated until later during page construction.

Therefore, at the time that bbp_new_topic_handler() processes the new topic request, the conditioning logic bp_group_is_member() fails to report accurately. If this were changed to condition on the $bp global (which IS already populated at the time that bbp_new_topic_handler runs), the capability remapping would occur early enough that these topics can be added to hidden forums!

For example, if I condition on:

if( 1 == $bp->groups->current_group->is_member )

I can grant myself the 'read_hidden_forums' capability early enough to post new topics!

<------------ Temporary Solution ---------------->

I'm using this function in the short term to get topic creation working in my hidden group forums. I don't suggest this as a long-term solution, but its a fix that doesn't require hacking core files.

add_filter( 'user_has_cap', 'hidden_group_forum_caps', 100 ,  3 );
function hidden_group_forum_caps( $allcaps, $cap, $args ) {

        /* Bail if we aren't in a group forum */
        if ( !defined( 'BP_VERSION' ) || !bp_is_groups_component() || !bp_is_current_action( 'forum' ) )
                return $allcaps;
                
        /* Otherwise check if the user is a group member */
        global $bp;
        if( 1 == $bp->groups->current_group->is_member ) {
                $allcaps['read_hidden_forums'] = true;
        }

        return $allcaps;
}

I hope this helps resolve the issue for a future bbPress release!
-Andrew

[3ruce]

Replying to aaclayton:

<------------ Temporary Solution ---------------->

I'm using this function in the short term to get topic creation working in my hidden group forums. I don't suggest this as a long-term solution, but its a fix that doesn't require hacking core files.

add_filter( 'user_has_cap', 'hidden_group_forum_caps', 100 ,  3 );
function hidden_group_forum_caps( $allcaps, $cap, $args ) {

        /* Bail if we aren't in a group forum */
        if ( !defined( 'BP_VERSION' ) || !bp_is_groups_component() || !bp_is_current_action( 'forum' ) )
                return $allcaps;
                
        /* Otherwise check if the user is a group member */
        global $bp;
        if( 1 == $bp->groups->current_group->is_member ) {
                $allcaps['read_hidden_forums'] = true;
        }

        return $allcaps;
}

I hope this helps resolve the issue for a future bbPress release!
-Andrew

Thank you for your input and perseverance Andrew! I've also got this issue having upgraded from earlier versions of bbpress - how do I get this temporary solution working? What file do I add the code to and at what line?

[aaclayton]

It just applies a filter to a bbpress function. It could be added anywhere in your theme's functions.php file. Let me know if it works in your case.

[johnjamesjacoby]

No time. Moving to 2.5.

[johnjamesjacoby]

Is this still happening? Possible it was fixed by #2119?

Moving to Future Release until feedback comes in. Thanks for your diligence.

[aaclayton]

I forgot this was still open, I believe #2119 took care of it, as I have no longer been having issues!