In-app notification title formatter assumes every ticket update is a status change — breaks for title/priority/description/category/type/visibility edits #84

New Issue

2026-09-01T00:08:16-04:00

jared commented

2026-09-01 00:08:16 -04:00

Severity: High

api/notifications.php (~lines 227-231) — the "update" notification title formatter unconditionally reads $details['status']['from']/['to'] for any action_type='update' audit row.

logTicketUpdate() (used by api/update_ticket.php:258) only includes a status key in details when status is one of the fields that actually changed. A title-only, priority-only, description-only, category-only, or type-only edit produces a delta with no status key at all; the visibility-change log entry (update_ticket.php:227-241) uses a flat {field, from, to} shape, not {status:{from,to}}.

Impact: In every one of these cases, PHP's ?? treats the missing/mismatched key as unset and falls through to '?' for both sides, so the bell notification literally reads "{user} changed status on #123: ? → ?" regardless of what was actually changed — a title edit, a priority bump, a visibility change, anything. This is a broader, more general version of the already-filed bulk-operation-specific issue (#74) — that one covers bulk operations logging the wrong shape; this one is the root formatter bug that also breaks for completely normal single-ticket, non-bulk, non-status edits made through the standard edit form.

Fix: Have the formatter branch on which key(s) are actually present in details (title/priority/status/description/category/type/visibility field) and render the correct human-readable line for each case, instead of assuming every update is a status change.

**Severity:** High `api/notifications.php` (~lines 227-231) — the "update" notification title formatter unconditionally reads `$details['status']['from']`/`['to']` for any `action_type='update'` audit row. `logTicketUpdate()` (used by `api/update_ticket.php:258`) only includes a `status` key in `details` when status is one of the fields that actually changed. A title-only, priority-only, description-only, category-only, or type-only edit produces a delta with **no `status` key at all**; the visibility-change log entry (`update_ticket.php:227-241`) uses a flat `{field, from, to}` shape, not `{status:{from,to}}`. **Impact:** In every one of these cases, PHP's `??` treats the missing/mismatched key as unset and falls through to `'?'` for both sides, so the bell notification literally reads **"{user} changed status on #123: ? → ?"** regardless of what was actually changed — a title edit, a priority bump, a visibility change, anything. This is a broader, more general version of the already-filed bulk-operation-specific issue (#74) — that one covers bulk operations logging the wrong shape; this one is the root formatter bug that also breaks for completely normal single-ticket, non-bulk, non-status edits made through the standard edit form. **Fix:** Have the formatter branch on which key(s) are actually present in `details` (title/priority/status/description/category/type/visibility field) and render the correct human-readable line for each case, instead of assuming every update is a status change.

jared added the notifications priority/high labels 2026-09-08 10:15:48 -04:00

jared referenced this issue from a commit

2026-09-08 11:59:38 -04:00

Notification titles: handle non-status ticket edits (#84)

jared referenced this issue from a commit

2026-09-08 15:39:41 -04:00

Merge development into main: 15-issue triage + fix batch

Sign in to join this conversation.