Skip to:
Content

BuddyPress.org

Opened 13 years ago

Closed 7 years ago

#3857 closed enhancement (maybelater)

Stop using hide_sitewide for privacy purposes

Reported by: boonebgorges's profile boonebgorges Owned by: boonebgorges's profile boonebgorges
Milestone: Priority: major
Severity: normal Version:
Component: Activity Keywords: trac-tidy-2018
Cc: chrisclayton, zane@…

Description

We currently mark activity items as hide_sitewide in two cases:

  • The activity item is duplicated by another one that is *not* hide_sitewide, is in the case of "John is friends with Boone" (hide_sitewide = 0) and "Boone is friends with John" (hide_sitewide = 1).
  • The activity item is not supposed to be shown to all members because of a privacy setting. In practice, this means that it was created in a hidden or private group, but in theory it could be for any reason.

We should stop using hide_sitewide for this purpose. It causes lots of problems. Here are just the few I could find in a couple minutes' search:
http://buddypress.trac.wordpress.org/ticket/2678
http://buddypress.trac.wordpress.org/ticket/3463
http://buddypress.trac.wordpress.org/ticket/2293

The only real surefire way to protect content in hidden/private groups is to do the proper queries at runtime. We might use logic like this in the activity query:

$non_public_group_ids = ids of all groups that are non-public
if ( is_user_logged_in() ) {
  $this_user_group_ids = ids of all this user's groups
  select from activity table where ( component != 'groups' OR item_id NOT IN ($non_public_group_ids) OR item_id IN ($this_user_group_ids) )
} else {
  select from activity table where ( component != 'groups' OR item_id NOT IN ($non_public_group_ids) )
}

This is going to make our query a bit slower, unfortunately. But we can aggressively cache the values of $non_public_group_ids and $this_user_group_ids, so that persistent caching will mostly eliminate those two queries.

Again, this is the only way to be really certain about this privacy stuff, so I think we have to do something like it. hide_sitewide has sorta worked up through now, but only just barely, and only through some hacks. Let's do it right, so that when and if we introduce finer-grained activity controls in BP core we will already have an example of how it ought to be done.

Let's talk about this early in the 1.7 cycle. It's something that's bothered me since I started using BP, so I would be happy to take it on as one of my tasks.

Change History (7)

#1 @boonebgorges
13 years ago

  • Keywords 1.7-early removed

I have a feeling that this is going to take way more than we have time for in the 1.7 release, so I'm going to preemptively punt it (much as it pains me to do so).

#2 @chrisclayton
12 years ago

  • Cc chrisclayton added

#3 @dcavins
11 years ago

Boone, I agree with doing this query based on the user's capabilities and memberships rather than some combination of group visibility and hide_sitewide. How many classes of activity are there? I'm guessing, here:

Public activity
Friendships, new members, activity in public groups

Limited audience activity
Activity in private and hidden groups, activity to be seen only by friends

Private activity
User-only, like creation of a private bp-doc

From your comments on other tickets, it seems you think a single "hide_sitewide" isn't enough to work with? What are you thinking, a "this is private" and "this is a duplicate of another activity"?

Please let me know if there's anything I can do to help out on this ticket.

-David

#4 @boonebgorges
11 years ago

To be honest, I don't have any bright ideas about how to solve this very large problem. The taxonomy of activity types you've laid out is a start, but the idea of "limited audience" is itself very complicated, because the "limited audience" will differ with each piece of data (depending on group membership and stuff like that). At the moment, I don't think BP has any concept of user-only activity, though I can see the use for it and how it fits into the larger picture.

What are you thinking, a "this is private" and "this is a duplicate of another activity"?

I think this is probably too simple, but yes, at a bare minimum I think that these should be handled separately.

Ultimately, I think we should also be thinking about finer-grained visibily stuff as we pick apart the puzzle at hand. It may never be the case that BP itself allows you to set per-activity visibility - show this activity item only to my friends, show this one publicly, etc - but whatever new system is developed should be theoretically compatible with a plugin that'd add the additional functionality.

Any ideas or sketches would be most welcome.

#5 @Zane
11 years ago

  • Cc zane@… added

#6 @DJPaul
7 years ago

  • Keywords trac-tidy-2018 added

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: https://make.wordpress.org/chat/

#7 @DJPaul
7 years ago

  • Milestone Awaiting Contributions deleted
  • Resolution set to maybelater
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.