Skip to:
Content

BuddyPress.org

Opened 10 years ago

Closed 10 years ago

#6169 closed defect (bug) (fixed)

Group activities on group's home : only the activities the logged in user posted are displayed

Reported by: imath's profile imath Owned by: johnjamesjacoby's profile johnjamesjacoby
Milestone: 2.2 Priority: high
Severity: blocker Version:
Component: Activity Keywords: has-patch
Cc:

Description (last modified by imath)

In version 2.1, the super admin was able to view the activities of an hidden/private group even if he wasn't a part of. It's no more the case.

Actually, after using different user logins, the problem seems to be : in the case of private/hidden groups only the activities of the current logged in user are displayed.

I think we really need to fix this as it's a regression.

Attachments (3)

6169.unittest.patch (1.9 KB) - added by imath 10 years ago.
6169.diff (2.7 KB) - added by boonebgorges 10 years ago.
6169.02.patch (9.6 KB) - added by r-a-y 10 years ago.

Download all attachments as: .zip

Change History (15)

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


10 years ago

#2 @imath
10 years ago

  • Summary changed from Private/Hidden Group activities are not shown to the superadmin to Private/Hidden Group activities : only the activities the logged in user posted are displayed

#3 @imath
10 years ago

  • Description modified (diff)
  • Summary changed from Private/Hidden Group activities : only the activities the logged in user posted are displayed to Group activities on group's home : only the activities the logged in user posted are displayed

#4 @imath
10 years ago

Actually no matter the group status. Only the activities the logged in user posted are displayed.

@boonebgorges
10 years ago

#5 @boonebgorges
10 years ago

6169.diff is a conservative patch that checks against the same scope whitelist as in 2.1.

A more correct fix, IMO, is to remove this bit from bp_has_activities() altogether, and move it into individual scope_args filters. I'm guessing this was not done initially to avoid lots of repetition. But as things stand, we're parsing scope in two different places, and besides this bug, it also makes debugging more complex.

This ticket was mentioned in Slack in #buddypress by r-a-y. View the logs.


10 years ago

@r-a-y
10 years ago

#7 @r-a-y
10 years ago

  • Keywords has-patch added; needs-patch removed

02.patch follows the recommendations in comment:5 and passes imath's unit test.

Something to note, right now for the sitewide visibility, we check the passed user ID against the logged-in user, but in a future release, we could probably also check if the logged-in user has the 'bp_moderate' cap. That way, BP mods can view hidden content directly on a user's profile.

#8 @imath
10 years ago

thanks a lot for your patch r-a-y. Just tested it, and i confirm it's fixing the issue

#9 @boonebgorges
10 years ago

This patch looks like the right fix. I'm glad we'll ship 2.2 with this fix, as it makes the whole system make a lot more sense (IMHO).

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


10 years ago

#11 @johnjamesjacoby
10 years ago

In 9405:

Add unit tests for bp_has_activities() to test results with different group privacies. Props imath. See #6169.

#12 @johnjamesjacoby
10 years ago

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

In 9406:

Move $user_id abstraction out of bp_get_activities() and into their respective scope filters.

This fixes a regression from Activity Query scope improvements causing private and hidden group activity queries to intersect with user ID's, resulting in unexpected activity stream items being displayed.

Tests included in r9405.

Props r-a-y. Fixes #6169.

Note: See TracTickets for help on using tickets.