Do we need to edit activity visibility when a user is marked as spam?

[imath]

Hi @emaralive,

Could you have a look at this?

When marking a user as spam in bp_core_process_spammer_status() we are updating their activity visibility to hide_sitewide = 1.

And we are also marking these activities as spam in bp_activity_spam_all_user_data() and running another update query to SET is_spam = 1

=> imho we could run one update query to set is_spam and hide_sitewide to save a query...

If the same user is marked as ham: in bp_activity_ham_all_user_data() we are updating is_spam accordingly but not hide_sitewide: meaning corresponding activities will only show on user's profile page when he's viewing his own profile, they shouldn't be listed into the BP Activity directory if I guess well.

Is this the behavior we should use?

[johnjamesjacoby]

Always great to reduce number of database writes.

If there are separate hooks firing inside of each function, or if these functions are called elsewhere for other reasons, they may be difficult to merge into 1 without risking breaking a third-party plugin.

[emaralive]

I alluded to that notion in #8728 and the following is an excerpt (specifically, the last table row):

---

Mark/Unmark User as Spammer

Only available to site admin via various locations

• Backend - [All] Users screen/page.
• Backend - Individual User's Extended Profile screen/page - Status metabox.
• Frontend - Individual User's Members Capabilities screen/page, e.g. site.urlmembers/{user}/settings/capabilities/

Note

1. user_status is a field in the users table.
2. hide_sitewide is a field in the bp_activity table, visible from backend - activity page/screen.
3. is_spam is a field in the bp_activity table, visible from backend - activity page/screen - spam tab.

state	user_status	hide_sitewide	is_spam	Note
Normal	0	0	0
Spammed	1	1	1	Kicked from site unable to log back in until unspammed.
Unspammed	0	1	0	Able to log in, but previous activity post are hidden

---

That stated, I believe we need to game out various scenarios that should shed light as to what should actually occur or maybe these situations don't matter, e.g.:

• User has some activities marked as spam and then is classified as a spammer.
• User is classified as spammer from initial behavior (broke a site rule, as an example)
• User was accidentally/unduly classified as a spammer.

However, one would think that if a user is "marked as ham" (unspammed/not spam) their activities should have "hide_sitewide" set back to 0 (zero). IIRC, currently the site admin has to do that manually by manipulating the "bp_activity" table. This opens another can of worms because the "hide_sitewide" field allows a "null" to be set (see ​src/bp-core/admin/bp-core-admin-schema.php#L137), which appears to keep the activity hidden.

[imath]

Thanks a lot for your researches @emaralive. I believe we don't need to hide activities when spamming a user, as spammed activities are not displayed into public feeds: this way we don't need to set it back to visible when marking a user as ham, as you described into your last paragraph.

I suspect hiding activities was the way we were using (since 1.2.0) before spamming/hamming functions like bp_activity_mark_as_spam() were introduced in 1.6.0.

Meaning we could deprecate bp_activity_hide_user_activity() as this function is only used when spamming a user (cc @johnjamesjacoby).

[emaralive]

@imath,

From what I can tell bp_activity_hide_user_activity() is called from within bp_core_process_spammer_status() (see ​src/bp-members/bp-members-functions.php#L817), thus deprecating the aforementioned function and removing lines 815 through 818 as well any applicable lines for spacing consideration from the aforementioned file seems pretty straightforward, unless I'm missing something that isn't readily apparent to me, at the moment.

Additionally, I think there is opportunity to visit or revisit Activity Moderation, perhaps in a different ticket, because reliance on 3rd party plugins to perform such services may not be optimal for a variety of reasons:

• Some require payment, IOW they are commercial must pay to download and use.
  • ​BuddyPress Moderation Tools by BuddyDev
  • ​BuddyPress Moderation by Youzify
• Some may be free to start but require payment for other features, i.e., the most useful ones.
  • ​Block, Suspend, Report for BuddyPress by Bouncingsprout Studio

And, of course, there is ​Akismet Anti-spam: Spam Protection that seems to be on the verge of commercialism. As an aside, I have noticed that there is code within BP that is relevant to Akismet, just saying. The bottom line or my point is that the BuddyPress Team should be considering how to fill, from what I can see, an obvious void.

[imath]

Thanks for your inputs @emaralive 👍.

About Activity Moderation, we need another ticket: you're right.

This ticket is relative to #9167