#2140 closed defect (bug) (fixed)
Extend Buddypress Group Forums Capabilities
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | trunk |
Component: | Extend - 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)
Change History (17)
#2
in reply to:
↑ description
@
12 years ago
#3
@
12 years 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.
#6
@
12 years 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.
#8
@
12 years 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.
#9
@
12 years 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.
#10
follow-up:
↓ 11
@
12 years 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
#11
in reply to:
↑ 10
@
12 years 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?
#12
@
12 years 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.
#14
@
11 years 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.
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.