[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:               |
-------------------------+------------------------------

Comment (by indigetal):

 Scope refinement before opening PR

 Thanks for considering this enhancement. Before opening the PR, I re-
 validated the implementation surface against current BuddyPress `master`
 and ran a targeted risk analysis. The proposal direction is unchanged
 (core storage + query support only), but the implementation scope has been
 refined to avoid rollout and write-path inconsistencies.

 == What changed since the original proposal

 The original proposal described ~4 files. The updated implementation scope
 is broader to keep behavior consistent across existing activity write/read
 paths:

 {{{
 src/bp-core/admin/bp-core-admin-schema.php
 src/bp-activity/classes/class-bp-activity-activity.php
 src/bp-activity/bp-activity-functions.php
 src/bp-groups/bp-groups-activity.php
 src/bp-activity/classes/class-bp-activity-query.php
 src/bp-activity/classes/class-bp-activity-rest-controller.php
 src/class-buddypress.php
 (possibly src/bp-core/bp-core-update.php only if needed by
 release/versioning expectations)
 }}}

 == Why the scope expanded

 1. `bp_activity_add()` and helper write paths:
    - Adding `privacy` only in the model is not sufficient.
    - `bp_activity_post_update()` / group update helper paths can rebuild
 payloads, so `privacy` must be preserved through those branches too.

 2. Hydration consistency:
    - `SELECT *` exists, but `populate()` and list hydration paths still
 map/cast explicit fields.
    - `privacy` needs explicit hydration handling to avoid path-dependent
 object state.

 3. Query compatibility:
    - `BP_Activity_Query` validates allowed columns.
    - `privacy` must be added to `BP_Activity_Query::$db_columns` so
 `filter_query`-based callers can use it.

 4. REST correctness:
    - Current class is `BP_Activity_REST_Controller` (file: `class-bp-
 activity-rest-controller.php`).
    - Response, schema, and DB-prep paths need synchronized updates for
 read/write parity.

 5. Upgrade sequencing:
    - Runtime SQL paths that reference `privacy` require schema
 availability on upgraded sites.
    - DB version bump is part of safe rollout sequencing so upgrade/install
 paths apply the column before these code paths are relied on.

 == Risk analysis summary

 I classified identified risks as follows:

  * '''Mitigable''' - Upgrade sequencing (schema + DB version + runtime SQL
 usage)
  * '''Mitigable''' - Shared model fanout (`populate()`, `save()`, `get()`,
 list hydration)
  * '''Mitigable''' - REST contract expansion (new writable/readable field)
  * '''Mitigable (high priority)''' - REST write-branch divergence
 (`activity_update` helper path vs direct `bp_activity_add()`)
  * '''Safe / intentional''' - `filter_query` behavior now allowing `column
 => 'privacy'`
  * '''Safe''' - Schema edit in isolation (additive)

 == Scope remains intentionally limited

 This is still a core infrastructure change only:

  * Add/store `privacy` column + index
  * Allow querying/filtering by `privacy`
  * Expose/accept `privacy` in REST
  * Keep defaults backward compatible (`'public'`)

 This does '''not''' introduce:

  * Core UI for privacy selection
  * Core enforcement policy for specific privacy values
  * A fixed enum of privacy values

 == Planned verification before PR submission

  * Verify schema upgrade path on existing installs (DB version gate +
 installer path)
  * Verify both REST create/update write branches persist `privacy`
  * Verify direct `bp_activity_add()` path persists `privacy`
  * Verify `BP_Activity_Activity::get()` and `filter_query` return expected
 results with `privacy`
  * Run focused fail-fast checks/linting on touched files

 I’ll open the PR once these refinements are implemented and validated, and
 link it back to this ticket.

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