Skip to:
Content

bbPress.org

Opened 5 years ago

Closed 2 years ago

#2593 closed defect (fixed)

Allow Moderators and Keymasters to see private topic content from users

Reported by: netweb Owned by: netweb
Milestone: 2.6 Priority: high
Severity: normal Version: trunk
Component: Component - Topics Keywords: needs-unit-tests has-patch
Cc:

Description

Support for this was added in r4564 as part of #2088, then changed in r4673 to only be available when when using ?view=all.

Patch adds back support to users who have the read_private_replies to see users private topic content.

Reported via bbpress.org

Attachments (1)

2593.diff (972 bytes) - added by netweb 5 years ago.

Download all attachments as: .zip

Change History (18)

@netweb
5 years ago

#1 follow-up: @mlocke90
5 years ago

Should this patch allow anyone who has the read_private_replies cap to see topic content? or just the Admin / keymaster?

I applied the code and it seemed to fix it for admin / keymasters but not for a custom role with read_private_replies cap.

#2 in reply to: ↑ 1 @netweb
5 years ago

Replying to mlocke90:

Should this patch allow anyone who has the read_private_replies cap to see topic content? or just the Admin / keymaster?

I applied the code and it seemed to fix it for admin / keymasters but not for a custom role with read_private_replies cap.

The patch should work fine for any user with the capability read_private_replies which includes the included bbPress Keymaster and Moderator. Are you sure the user/role you are using has the read_private_replies capability?

Install this plugin,go to the users profile in the WordPress dashboard to confirm the role and capability of a user.

#3 @netweb
5 years ago

  • Keywords needs-unit-tests added

@mlocke90 Thanks for testing this. A bit more testing based on your comments here and here I cannot reproduce what you outlined. Can you confirm both the specific WordPress Role and bbPress Role you are seeing that behaviour with.

Users:

User1 WordPress Role - Subscriber bbPress Role: Participant
User2 WordPress Role - Subscriber bbPress Role: Moderator
User3 WordPress Role - Subscriber bbPress Role: Keymaster
User4 WordPress Role - Administrator bbPress Role: Keymaster

Forum: http://localhost/forums/forum/test-forum/
Topic: http://localhost/forums/topic/topic-test/

Without the patch:

Can view topic in forum listCan view private topic content
User1yesyes
User2yesno
User3yesno
User4yesno

With the patch:

Can view topic in forum listCan view private topic content
User1yesyes
User2yesyes
User3yesyes
User4yesyes

Logged out users can not see the topic in the forum list or view the topic at all.

#4 @mlocke90
5 years ago

Without the patch:
Can view topic in forum list / Can view private topic content

User1: no / no
User2: yes / no
User3: yes / no
User4: yes / no
With the patch:
Can view topic in forum list / Can view private topic content

User1: no / no
User2: yes / no
User3: yes / no
User4: yes / no

For whatever reason I cannot even view the topic in the front-end with admin / keymaster this time around. Before my tests I did a fresh install of both WP and BBpress.

#5 follow-up: @mlocke90
5 years ago

Am I possibly missing something when it comes to applying the patch? I'm simply taking the includes/replies/template.php from the svn and replacing my old one.

#6 @mlocke90
5 years ago

I did some more troubleshooting to figure out why I can see private topics while logged into a wordpress admin account on my live site and not on a fresh install.

The culprit ended up being the Groups plugin (https://wordpress.org/plugins/groups/), more specifically the option to allow admins to override all group capabilities. Once I deactivated the plugin I was back to getting the results I posted above. Only the topic author can see the topic content, this includes admins / keymasters.

#7 in reply to: ↑ 5 @netweb
5 years ago

Replying to mlocke90:

Am I possibly missing something when it comes to applying the patch? I'm simply taking the includes/replies/template.php from the svn and replacing my old one.

This.

The patch has not yet been committed to repo yet, so testing and verified by other devs and testers before it gets added to the core files. We are at the moment beginning to implement PHPUnit tests to bbPress and this type of ticket is one that will benefit greatly from this automated testing. It will allow us to automatically check all of the permutations and combinations of what I did manually above which is a) faster and b) should ensure we don't break anything new or backwards compatability.

There are some guides on applying patches here, they are based on WordPress but the process is identical for bbPress with changes the URLs of our source files and svn repository etc.

#8 @netweb
5 years ago

  • Owner set to netweb

#9 @johnjamesjacoby
5 years ago

Having two separate current_user_can( 'read_private_replies' ) checks seems unnecessary here.

Also:

  • Should we consider adding pending, maybe with a read_pending_replies meta cap?
  • Should bbp_has_topics() have a similar treatment?

#10 @johnjamesjacoby
5 years ago

After rereading the relevant commit messages, the perm argument should be taking care of this for us. Let's investigate why it's not before attempting to override the queried post statuses.

#11 @netweb
5 years ago

Testing #459 with #2645, a specific forum moderator cannot read that forums pending topics, so this will also need testing, maybe commit #459 and then come back to this ticket and test 'all the things'.

#12 @johnjamesjacoby
3 years ago

  • Priority changed from normal to high

#459 is done-done. Let's look at this during 2.6 beta.

#13 @johnjamesjacoby
3 years ago

In 6384:

Moderation: Allow per-forum moderators to edit topics & replies inside of forums they have moderation control over.

This feature require the following changes:

  • Prefer read_forum capability check over read_private_forums or read_hidden_forums, and include a $forum_id parameter to assist map_meta_cap filters
  • Prefer edit_others_topics|replies over moderate where appropriate, to ensure capability mappings work as intended
  • Introduce bbp_get_public_topic_statuses() to replace several duplicate occurrences of the same array usage (also allow these to be filtered)
  • Introduce bbp_is_topic_public() (not to be confused with bbp_is_topic_published()) to provide parity with bbp_is_forum_public() and also utilize bbp_get_public_topic_statuses() from above
  • Add local caching to bbp_exclude_forum_ids() as a performance optimization to reduce the depth of current_user_can() calls when private & hidden forums are in use
  • Add user_can( 'moderate' ) capability checks to various mappings, to ensure forum moderators can read/edit/delete content inside of the individual forums they are moderators of
  • Use bbp_get_user_id() where appropriate, rather than casting as int
  • Various surrounding code clean-ups

See #2593.

This ticket was mentioned in Slack in #bbpress by jjj. View the logs.


2 years ago

#15 @johnjamesjacoby
2 years ago

In 6425:

Users: Introduce bbp_allow_forums_of_user().

This filter-only function will be used to remove private & hidden forums from being excluded in queries, for users who are explicitly allowed forums that they would not otherwise be able to access.

See #2593.

#16 @johnjamesjacoby
2 years ago

In 6426:

Users: Introduce bbp_get_excluded_forum_ids().

This function will be used in places where private & hidden forum IDs are combined to determine which forums should be excluded from specific queries.

See #2593.

#17 @johnjamesjacoby
2 years ago

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

In 6431:

Users: Connect bbp_allow_forums_of_user filter to bbp_get_excluded_forum_ids filter.

This prevents excluding private or hidden forums that the currently logged in user can explicitly moderate.

Fixes #2593.

Note: See TracTickets for help on using tickets.