Skip to:
Content

Opened 16 months ago

Closed 5 months ago

Last modified 4 months ago

#2140 closed defect (fixed)

Extend Buddypress Group Forums Capabilities

Reported by: aaclayton Owned by:
Milestone: Priority: normal
Severity: normal Version: trunk
Component: BuddyPress Keywords: reporter-feedback
Cc: mercijavier@…, jmdodd@…, 3ruce

Description

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' ) )

Attachments (1)

2140.patch (856 bytes) - added by johnjamesjacoby 15 months ago.
Address the recursive map_topic_meta_caps() issue

Download all attachments as: .zip

Change History (17)

comment:1 mercime16 months ago

  • Cc mercijavier@… added

comment:2 in reply to: ↑ description aaclayton16 months ago

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.

comment:3 aaclayton16 months ago

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.

comment:4 jmdodd16 months ago

  • Cc jmdodd@… added

comment:5 johnjamesjacoby16 months ago

  • Milestone changed from Awaiting Review to 2.3

johnjamesjacoby15 months ago

Address the recursive map_topic_meta_caps() issue

comment:6 johnjamesjacoby15 months ago

  • Resolution set to fixed
  • Status changed from new to closed

(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.

comment:7 johnjamesjacoby15 months ago

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

comment:8 johnjamesjacoby15 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:9 johnjamesjacoby15 months ago

  • Milestone changed from 2.3 to 2.4

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.

comment:10 follow-up: aaclayton15 months ago

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

Last edited 15 months ago by aaclayton (previous) (diff)

comment:11 in reply to: ↑ 10 3ruce14 months ago

  • Cc 3ruce added

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?

comment:12 aaclayton14 months ago

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.

comment:13 johnjamesjacoby11 months ago

  • Milestone changed from 2.4 to 2.5

No time. Moving to 2.5.

comment:14 johnjamesjacoby5 months ago

  • Keywords reporter-feedback added; has-patch removed
  • Milestone changed from 2.5 to Future Release

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

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

comment:15 aaclayton5 months ago

  • Resolution set to fixed
  • Severity changed from major to normal
  • Status changed from reopened to closed

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

comment:16 johnjamesjacoby4 months ago

  • Milestone Future Release deleted
Note: See TracTickets for help on using tickets.