Member blocking

[r-a-y]

In #3695, we introduced basic profile privacy.

I think it's time that we start looking at other privacy features. The most rudimentary of that being member blocking.

Some things that need to be completed in order for this to work are:

1) Introduce a new relationship DB table

Usermeta is a bottleneck so we can't go that route.

We could leverage the existing activity table. It would be possible, but we'd need to do something similar with how we exclude last_activity items in the activity loop so it probably doesn't make sense to go this route.

I'm thinking of a new DB table so we can store miscellaneous relationships. This table can be potentially used by 3rd-party plugins to do some neat stuff.

Example: UserA blocks UserB

id	item_id	secondary_item_id	tertiary_item_id?	type
AUTOINCREMENT	ID of UserB	ID of UserA		member_block

UserA is logged-in, so we run the following DB queries:

SELECT item_id FROM {$new_table} WHERE secondary_item_id = {$id_of_userA} AND type = 'member_block'

This query grabs all user IDs that UserA has blocked.

SELECT secondary_item_id FROM {$new_table} WHERE item_id = {$id_of_userA} AND type = 'member_block'

This query grabs all user IDs that have blocked UserA.

We'll merge these results and use them in various template loops. The member loop already has an exclude parameter, which we can use.

The activity loop doesn't. See point 2.

---

2) Activity - Exclude activities by user ID

We currently have a user_id parameter in bp_has_activities() that allows us to filter activity items by user ID.

We also need a way to exclude activity items by user ID.

I see two approaches:

• Introduce a new parameter like exclude_user_ids that works similar to user_id but uses a NOT IN SQL query
• Use WP_Query's author syntax. For example author=-1 would exclude items by user ID 1

---

3) Various UX stuff

• Need a button to block a member; Need to show a notice if a blocked member attempts to view a user's page who blocked that user.

• Hook into all other default components that need some form of filtering - private messaging, friends, xprofile

• Activity at-mention filtering is tricky. How do we want to handle at-mentions when a user blocks another?

The scenario in section 1 outlines what happens when a user blocks another user. This wouldn't affect logged-out scenarios. How do we solve this?

Twitter has a public / protected account status. When a Twitter user has a protected account status, only followers can view this person's tweets.

The closest thing we have in core is XProfile's visibility module that we could potentially leverage, however to access these levels, we'd need the XProfile component enabled at all times. (Related: #4728.) This would actually be a separate feature / ticket. This feature could potentially be built directly into the XProfile component, however there are also concerns with fetching this data for use in template loops.

Just wanted to get the ball rolling with some thoughts.

I've put this in future release. But, might move to the 2.1 milestone pending feedback.

[johnjamesjacoby]

I like this idea for object to object relationships. I'd move type next to ID in the ordering, just so it's more clear when viewing the table itself. You could start writing this out as a plugin to start, and document & add any filters you need in core where they are missing. That way when we decide to incorporate something like this into core, it's an easy transition?

[shanebp]

Over a year ago I wrote this plugin ​http://www.philopress.com/products/buddyblock/ - it has been very popular.

It basically follows r-a-y's description, except that the db table only has the first 3 fields.

This table can be potentially used by 3rd-party plugins to do some neat stuff.

Yes, it'd be great for things like teacher > students, parents > progeny.

re #2 Activity - I just use the 'bp_activity_get_where_conditions' filter and add a couple NOT IN $blocked_ids to the $where_conditions array

Activity at-mention filtering is tricky.

Yes. Not difficult to remove, but rather should they be removed?
So it's a UX issue.
Members will want to know about public comments directed at them.
"She said what about me?"

I suggest that at-mentions not be removed, but a Report Abuse system be added.

My plugin also does a few misc items you may want for the Description:

• admins can't be blocked
• admin screen to see who is blocking who, and create blocks
• grant 'blocking permissions' to designated roles
• cancel any friendships with the blocked member

Although it would render a premium plugin obsolete, it'd be cool to see this in core, especially a relationships table.

So if a core wants to peruse BuddyBlock, just ask.

To see my plugin roster, visit ​http://www.philopress.com/.
I just released a couple of Group plugins.

[DJPaul]

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/