Skip to:
Content

BuddyPress.org

Opened 12 years ago

Closed 12 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 Owned by: johnjamesjacoby
Priority: high Milestone: 2.2
Component: Activity Version:
Severity: blocker 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 12 years ago.
6169.diff (2.7 KB ) - added by boonebgorges 12 years ago.
6169.02.patch (9.6 KB ) - added by r-a-y 12 years ago.

Download all attachments as: .zip

Change History (15)

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


12 years ago

#2 @imath
12 years ago

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

#3 @imath
12 years ago

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

#4 @imath
12 years ago

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

@boonebgorges
12 years ago

#5 @boonebgorges
12 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.


12 years ago

@r-a-y
12 years ago

#7 @r-a-y
12 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
12 years ago

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

#9 @boonebgorges
12 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.


12 years ago

#11 @johnjamesjacoby
12 years ago

In 9405:

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

#12 @johnjamesjacoby
12 years ago

  • Owner set to johnjamesjacoby
  • Resolutionfixed
  • Status newclosed

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.