fix(security): scope dashboard stats/analytics/activity to the caller's events (stable) (#964)

* fix(security): scope dashboard endpoints to the caller's events (GHSA-c2jj, gqx7, jhcf)

/dashboard/stats, /analytics and /activity are gated only by analytics.view,
which the editor role holds — but the events LIST restricts editors to their
own rows (adminEvents/crud.js: roleName === 'editor' -> created_by =
admin.id). So an editor saw instance-wide totals, and via /analytics
topGalleries other admins' gallery NAMES and SLUGS (the public gallery URL
component), for events invisible to them everywhere else.

- stats: all 10 aggregates scoped (events by id, photos/access_logs by
  event_id).
- analytics: all 8 series/aggregates scoped, including topGalleries. The
  external tracker device breakdown reports instance-wide data with no event
  filter, so a scoped caller falls through to the access_logs heuristic
  instead, which IS scoped.
- activity: feed scoped. activity_logs.event_id is nullable and the join is a
  leftJoin, so system-level rows (logins, settings changes) are deliberately
  excluded for a scoped caller — those are precisely the cross-admin actions
  the advisory is about.

Scoping keys on 'editor' to mirror the events list exactly, so the admin
role's dashboard is unchanged. filterOwnedEventIds uses the broader
'!== super_admin' rule; the two conventions disagree in this codebase and
matching the list is the no-regression choice.

* fix(security): codex round 2 — fix activity misattribution, scope via subquery (GHSA-jhcf, c2jj, gqx7)

- expenseService passed adminId as logActivity's THIRD positional parameter,
  which is eventId — so admin ids were being written into
  activity_logs.event_id. The /activity scoping filter trusts that column, and
  admin/event id sequences overlap, so a foreign admin's expense metadata could
  surface under an editor's event. All 11 calls now pass null for eventId and
  the admin as the actor, which is what they meant.
- Dashboard scoping now uses a SUBQUERY instead of pluck()+whereIn. An editor
  owning more events than the driver's bind-parameter limit (~999 SQLite,
  65535 Postgres) would have turned all three endpoints into 500s once each id
  became a placeholder; below the limit it still re-sent the full list for each
  of the ~10 aggregates per request.

Note: two billInboundNow() calls also end in ', adminId)' but have an unrelated
signature — verified untouched.

* fix(security): codex round 3 — correct legacy accounting activity rows (GHSA-jhcf)

expenseService called logActivity(type, metadata, adminId), but logActivity's
third positional parameter is eventId. Every expense / incoming-invoice entry
therefore stored the ACTING ADMIN'S ID in activity_logs.event_id.

Round 2 scoped the activity feed with
`WHERE activity_logs.event_id IN (SELECT id FROM events WHERE created_by = me)`,
which does nothing about the rows already on disk. Admin ids and event ids are
small integers from the same range, so on any upgraded instance an editor who
owns the event whose id happens to equal another admin's id is served that
admin's accounting activity, verbatim metadata included — GHSA-jhcf, still
live. Migration 168 re-attributes those rows (event_id holds exactly the actor
id that was lost) and then clears event_id so the scope predicate can no longer
match them. All ten activity types are emitted by expenseService and nothing
else, so no row with a genuine event_id is touched.

Also: the round-2 rewrite passed `{ type: 'admin', id: adminId }`
unconditionally, which stored actor_type='admin' with a null id for the
automated mailbox intake (emailIntakeService calls recordInboundDocument with
no adminId). adminActor() restores 'system' attribution for those.

Claude-Session: https://claude.ai/code/session_01F211U4dDbEj4zXiyKbi9me
(cherry picked from commit 459e9e42434defd0dc7b87246e4d894dd47dcc56)

---------

Co-authored-by: Paul Nothaft <[email protected]>

backend/migrations/core/168_fix_expense_activity_event_id.js

@@ -0,0 +1,64 @@
+/**
+ * GHSA-jhcf — data correction for legacy accounting activity rows.
+ *
+ * expenseService called `logActivity(type, metadata, adminId)`, but the third
+ * positional parameter of logActivity is `eventId`, not the actor. Every
+ * expense / incoming-invoice entry therefore stored the ACTING ADMIN'S ID in
+ * `activity_logs.event_id` (and no actor at all).
+ *
+ * That is not merely cosmetic. The dashboard activity feed now scopes rows via
+ * `WHERE activity_logs.event_id IN (SELECT id FROM events WHERE created_by = me)`.
+ * Admin ids and event ids are both small integers drawn from the same range, so
+ * on any upgraded instance an editor who happens to own the event whose id
+ * equals another admin's id is served that admin's accounting activity —
+ * verbatim metadata included. Scoping new writes correctly does nothing for the
+ * rows already on disk, so they are corrected here.
+ *
+ * The stored value is exactly the actor id we lost, so this re-attributes
+ * rather than discards: event_id → actor_id (when no actor was recorded), then
+ * event_id is cleared so the scope predicate can no longer match it.
+ *
+ * All ten activity types below are emitted by expenseService and nothing else,
+ * so no row with a genuine event_id is touched.
+ */
+
+const AFFECTED_TYPES = [
+  'incoming_invoice_captured',
+  'incoming_invoice_updated',
+  'incoming_invoice_categorized',
+  'incoming_invoice_rebilled',
+  'incoming_invoices_rebilled_bundle',
+  'incoming_invoice_supplier_payment',
+  'expense_created',
+  'expense_updated',
+  'expense_invoiced',
+  'expense_paid',
+];
+
+exports.up = async function up(knex) {
+  if (!(await knex.schema.hasTable('activity_logs'))) return;
+  if (!(await knex.schema.hasColumn('activity_logs', 'event_id'))) return;
+
+  const hasActorId = await knex.schema.hasColumn('activity_logs', 'actor_id');
+  const hasActorType = await knex.schema.hasColumn('activity_logs', 'actor_type');
+
+  if (hasActorId) {
+    const patch = { actor_id: knex.ref('event_id') };
+    if (hasActorType) patch.actor_type = 'admin';
+    await knex('activity_logs')
+      .whereIn('activity_type', AFFECTED_TYPES)
+      .whereNotNull('event_id')
+      .whereNull('actor_id')
+      .update(patch);
+  }
+
+  await knex('activity_logs')
+    .whereIn('activity_type', AFFECTED_TYPES)
+    .whereNotNull('event_id')
+    .update({ event_id: null });
+};
+
+// Irreversible by design: this is a data correction, and the pre-migration
+// state is a cross-admin disclosure. Re-planting admin ids in event_id would
+// reopen GHSA-jhcf.
+exports.down = async function down() {};