[buddypress-trac] [BuddyPress Trac] #9327: Enhancement Request: Add `privacy` column to `bp_activity` for per-item visibility control

[buddypress-trac]

#9327: Enhancement Request: Add `privacy` column to `bp_activity` for per-item
visibility control
-------------------------+------------------------------
 Reporter:  indigetal    |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Activity     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |
-------------------------+------------------------------

Comment (by indigetal):

 Today, `hide_sitewide` covers one visibility case well: "keep an item off
 the sitewide stream." Many community sites and extensions need a separate,
 per-activity audience value, such as friends-only updates, logged-in-only
 posts, author-only notes, group-context visibility, and similar patterns
 that are common on modern social products. Without a first-class column,
 every plugin that needs this ends up inventing its own storage (custom
 columns, meta, or post-save workarounds) and its own query logic, which
 fragments behavior across the ecosystem.

 Landing `privacy` in core as storage + optional query/REST support (not UI
 or enforcement policy) would give themes and plugins a shared contract,
 similar to how `hide_sitewide` already works: core stores and exposes the
 value; extensions decide what values mean and who can see what.

 That would make it easier to build, in a consistent way:

 * Privacy-aware activity streams and directories (extensions filtering
 what the current viewer should see)
 * Search and discovery that respect activity audience, not only sitewide
 visibility
 * REST/mobile clients that can read and set audience metadata without one-
 off APIs per plugin
 * Group and profile posting flows that preserve audience when updates go
 through `bp_activity_add()` and related helpers

 We are not asking core to ship a full “privacy product” — no picker UI, no
 fixed enum, no built-in access rules. The goal is shared infrastructure so
 multiple independent plugins do not each fork activity persistence or
 reimplement the same column.

 PR #438 is ready for review when useful. Happy to adjust scope if
 maintainers prefer a smaller first step (for example schema + model only,
 REST in a follow-up).

 Thanks for considering it.

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