People feature with relatives, met-through, and notes #27

New issue

Closed

opened 2026-06-12 20:29:15 +00:00 by james · 0 comments

james commented

2026-06-12 20:29:15 +00:00

Owner

The richest single feature in the spec.

Scope

Each Person has:

Name, Gender, Pronouns, Contact info (multi-entry).
Organizations: each entry is either a link to a tracked Organization (#28) or a stub with only a name. Both forms must be supported. The linked Organization must be owned by the same user — you can't link to another user's Organization.
Relatives: list of (other Person ref, relationship type — at least spouse and child, extensible). Other Person refs must belong to the same user.
Met through: list of other Person refs. Same constraint.
Notes: each has a date and text.

Backend:

Entities + migrations for Person, Person↔Organization (with stub-name support), Relative, MetThrough, Note. All carry a user_id FK; denormalize the FK onto every child table (Note, Relative, MetThrough, Person↔Organization) for cheap isolation checks.
Full CRUD API + DTOs. All queries scoped to the authenticated user.
Tests on both DB engines, including the stub-organization case, the self-referential relationships, and cross-user isolation — including attempts to add another user's Person as a relative/met-through, which must fail cleanly with a 404 on the foreign Person.

Frontend:

People list + detail pages.
Note timeline view sorted by date (descending).

Acceptance criteria

All relationships round-trip correctly on both DB engines.
Deleting a Person removes their notes and removes their references from relatives/met-through lists on other people of the same user.
A Person referencing a stub organization works without an Organization row existing.
User A cannot read, reference, or modify any of User B's People, Notes, or relationship rows at any level.

Part of epic #5. Depends on #8, #10, #20.

The richest single feature in the spec. ## Scope Each Person has: - Name, Gender, Pronouns, Contact info (multi-entry). - **Organizations**: each entry is either a link to a tracked Organization (#28) **or** a stub with only a name. Both forms must be supported. **The linked Organization must be owned by the same user — you can't link to another user's Organization.** - **Relatives**: list of (other Person ref, relationship type — at least `spouse` and `child`, extensible). **Other Person refs must belong to the same user.** - **Met through**: list of other Person refs. **Same constraint.** - **Notes**: each has a date and text. Backend: - Entities + migrations for Person, Person↔Organization (with stub-name support), Relative, MetThrough, Note. **All carry a `user_id` FK; denormalize the FK onto every child table (Note, Relative, MetThrough, Person↔Organization) for cheap isolation checks.** - Full CRUD API + DTOs. **All queries scoped to the authenticated user.** - Tests on both DB engines, including the stub-organization case, the self-referential relationships, **and cross-user isolation — including attempts to add another user's Person as a relative/met-through, which must fail cleanly with a 404 on the foreign Person**. Frontend: - People list + detail pages. - Note timeline view sorted by date (descending). ## Acceptance criteria - [ ] All relationships round-trip correctly on both DB engines. - [ ] Deleting a Person removes their notes and removes their references from relatives/met-through lists on other people **of the same user**. - [ ] A Person referencing a stub organization works without an Organization row existing. - [ ] User A cannot read, reference, or modify any of User B's People, Notes, or relationship rows at any level. Part of epic #5. Depends on #8, #10, #20.

james referenced this issue

2026-06-12 20:29:18 +00:00

Organizations feature #28

james added the

area:pwa

area:service

feature

labels

2026-06-12 20:32:14 +00:00

james referenced this issue from a commit

2026-06-24 00:38:34 +00:00

feat(db): people + organizations tables, repos, and dual-engine tests (#27)