Application status updates (dated notes timeline) #133

New issue

Open

opened 2026-06-19 13:26:29 +00:00 by james · 0 comments

james commented

2026-06-19 13:26:29 +00:00

Owner

Let a user add timestamped status updates to an application — short journal entries that capture what happened and when — and view them as a chronological timeline.

This is distinct from the application's own status enum (Open / Started / Submitted / etc.): the enum captures where the application stands now, status updates capture the running history (e.g. "2026-07-02 — recruiter called, scheduling first round next week").

Scope

New application_status_updates table: (id, user_id, application_id, event_date, notes, created_at, updated_at). user_id and application_id both FK + indexed. event_date is the user-supplied date the update is about (separate from created_at, the row's wall-clock creation).
Entity in db/entities/application-status-update.ts; repository in db/repositories/application-status-updates.ts; migration under db/migrations/.
DTO + zod schema in lib/dto/application-status-update.ts. notes is a free-text field; event_date is a date (no time component, to match the user-facing model).
API routes under app/api/applications/[id]/status-updates/ — list, create, get, update, delete. Session-authed, per-user scoped, cross-user IDs return 404.
PWA: a Status updates timeline on the application detail page — newest first, with date and notes; add / edit / delete inline. TanStack Query for the list; TanStack Form for the editor.
Cross-engine tests for the entity round-trip, per-user isolation, and the API routes.

Acceptance criteria

application_status_updates migration applies on startup, both engines.
A user can add a status update to an application with a date and notes, see it in the timeline (newest first), edit it, and delete it.
Status updates are independent of the application's status enum — neither field changes the other.
User B cannot see or modify user A's status updates — cross-user IDs return 404.
Tests run on both DB engines.

Part of epic #129. Depends on the Application core ticket landing first.

Let a user add timestamped status updates to an application — short journal entries that capture what happened and when — and view them as a chronological timeline. This is distinct from the application's own `status` enum (Open / Started / Submitted / etc.): the enum captures *where the application stands now*, status updates capture *the running history* (e.g. "2026-07-02 — recruiter called, scheduling first round next week"). ## Scope - New `application_status_updates` table: `(id, user_id, application_id, event_date, notes, created_at, updated_at)`. `user_id` and `application_id` both FK + indexed. `event_date` is the user-supplied date the update is *about* (separate from `created_at`, the row's wall-clock creation). - Entity in `db/entities/application-status-update.ts`; repository in `db/repositories/application-status-updates.ts`; migration under `db/migrations/`. - DTO + zod schema in `lib/dto/application-status-update.ts`. `notes` is a free-text field; `event_date` is a date (no time component, to match the user-facing model). - API routes under `app/api/applications/[id]/status-updates/` — list, create, get, update, delete. Session-authed, per-user scoped, cross-user IDs return 404. - PWA: a Status updates timeline on the application detail page — newest first, with date and notes; add / edit / delete inline. TanStack Query for the list; TanStack Form for the editor. - Cross-engine tests for the entity round-trip, per-user isolation, and the API routes. ## Acceptance criteria - [ ] `application_status_updates` migration applies on startup, both engines. - [ ] A user can add a status update to an application with a date and notes, see it in the timeline (newest first), edit it, and delete it. - [ ] Status updates are independent of the application's `status` enum — neither field changes the other. - [ ] User B cannot see or modify user A's status updates — cross-user IDs return 404. - [ ] Tests run on both DB engines. Part of epic #129. Depends on the Application core ticket landing first.

james added the

area:db

area:pwa

area:service

labels

2026-06-19 13:27:26 +00:00