[buddypress-trac] [BuddyPress Trac] #5665: Member blocking

[buddypress-trac]

#5665: Member blocking
--------------------------+-----------------------------
 Reporter:  r-a-y         |       Owner:
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  Members       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  dev-feedback  |
--------------------------+-----------------------------
Description changed by r-a-y:

Old description:

> 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.  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.

New description:

 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.

--

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5665#comment:3>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac