feat(relationship): editable relationships with LocalDate+DatePrecision dates and notes #841

Merged

marcel merged 11 commits from feat/issue-837-relationship-edit-dates into main 2026-06-14 21:17:38 +02:00

Conversation 0 Commits 11 Files Changed 59 +2196 -580

marcel commented 2026-06-14 19:42:45 +02:00

Owner

Copy Link

Closes #837

Makes PersonRelationship fully editable (type, related person, dates, notes), migrates its dates from Integer fromYear/toYear to LocalDate + DatePrecision (mirroring the #773 person pattern, ADR-039 / V76), activates the previously-dead notes column, and gives the Zeitstrahl's derived Heirat events full date precision for free.

Both Open Decisions confirmed as adopted: no @Version (last-write-wins, single-writer archive) and DELETE ownership-mismatch aligned 403 → 404 (anti-enumeration, matching the new PUT).

What's in it

• V78 migrates person_relationships.from_year/to_year → from_date/to_date + NOT-NULL *_date_precision (default UNKNOWN); pre-check abort on corrupt years, YYYY-01-01/YEAR backfill, 5 named CHECK constraints, year columns dropped.
• PUT /api/persons/{id}/relationships/{relId} (@RequirePermission(WRITE_ALL)) re-runs every create invariant (self / coherence / order / reverse-PARENT_OF / duplicate) and re-flags family membership; orientation preserved per viewpoint.
• New ErrorCode.INVALID_RELATIONSHIP_DATES registered in all four sites (§3.6).
• TimelineEventService sources the derived marriage date from SPOUSE_OF.fromDate + precision.
• Frontend: RelationshipDateField (DAY/MONTH/YEAR), upsert-capable AddRelationshipForm (pre-fill + notes + in-flight submit lock), RelationshipChip Edit affordance, updateRelationship server action, read-view date range + notes, formatRelationshipDateRange helper. api.ts regenerated.
• Docs: ADR-044, db-orm/db-relationships diagrams, DEPLOYMENT §5 deploy note, RTM REQ-001…REQ-019.

Requirements

All 19 EARS requirements implemented red/green and marked Done in .specify/rtm.md.

Test plan

• Backend (targeted, green): RelationshipMigrationTest (Testcontainers pg16, 8), RelationshipServiceTest (22), RelationshipControllerTest (15), RelationshipServiceIntegrationTest (real DB, 10), DerivedEventsAssemblyTest (17), ArchitectureTest (14); clean package builds.
• Frontend (green): relationshipDates.spec.ts, AddRelationshipForm.svelte.spec.ts, RelationshipChip.svelte.spec.ts, PersonRelationshipsCard.svelte.test.ts, page.server.spec.ts, messages.spec.ts. npm run check = 798 (below the ~834 baseline); npm run lint clean.

Notes for reviewers

• Spec deviation: the edit form was built by making AddRelationshipForm upsert-capable rather than a duplicate EditRelationshipForm (DRY); RTM rows reference AddRelationshipForm.svelte.spec.ts.
• api.ts regenerated from the live spec; only relationship-relevant hunks remain (one springdoc PageableObject field-reorder pruned).
• Deploy: V78 is one-way and not rolling-deploy-safe — stop old JAR → start new JAR (Flyway runs first); targeted pg_restore -t person_relationships for rollback. No maintenance window.

🤖 Generated with Claude Code

Closes #837 Makes `PersonRelationship` fully editable (type, related person, dates, notes), migrates its dates from `Integer fromYear/toYear` to `LocalDate + DatePrecision` (mirroring the #773 person pattern, ADR-039 / V76), activates the previously-dead `notes` column, and gives the Zeitstrahl's derived **Heirat** events full date precision for free. Both Open Decisions confirmed as adopted: **no `@Version`** (last-write-wins, single-writer archive) and **`DELETE` ownership-mismatch aligned 403 → 404** (anti-enumeration, matching the new `PUT`). ## What's in it - **V78** migrates `person_relationships.from_year/to_year` → `from_date`/`to_date` + NOT-NULL `*_date_precision` (default `UNKNOWN`); pre-check abort on corrupt years, `YYYY-01-01`/`YEAR` backfill, 5 named CHECK constraints, year columns dropped. - **`PUT /api/persons/{id}/relationships/{relId}`** (`@RequirePermission(WRITE_ALL)`) re-runs every create invariant (self / coherence / order / reverse-PARENT_OF / duplicate) and re-flags family membership; orientation preserved per viewpoint. - New `ErrorCode.INVALID_RELATIONSHIP_DATES` registered in all four sites (§3.6). - `TimelineEventService` sources the derived marriage date from `SPOUSE_OF.fromDate` + precision. - Frontend: `RelationshipDateField` (DAY/MONTH/YEAR), upsert-capable `AddRelationshipForm` (pre-fill + notes + in-flight submit lock), `RelationshipChip` Edit affordance, `updateRelationship` server action, read-view date range + notes, `formatRelationshipDateRange` helper. `api.ts` regenerated. - Docs: ADR-044, db-orm/db-relationships diagrams, DEPLOYMENT §5 deploy note, RTM REQ-001…REQ-019. ## Requirements All 19 EARS requirements implemented red/green and marked `Done` in `.specify/rtm.md`. ## Test plan - **Backend** (targeted, green): `RelationshipMigrationTest` (Testcontainers pg16, 8), `RelationshipServiceTest` (22), `RelationshipControllerTest` (15), `RelationshipServiceIntegrationTest` (real DB, 10), `DerivedEventsAssemblyTest` (17), `ArchitectureTest` (14); `clean package` builds. - **Frontend** (green): `relationshipDates.spec.ts`, `AddRelationshipForm.svelte.spec.ts`, `RelationshipChip.svelte.spec.ts`, `PersonRelationshipsCard.svelte.test.ts`, `page.server.spec.ts`, `messages.spec.ts`. `npm run check` = 798 (below the ~834 baseline); `npm run lint` clean. ## Notes for reviewers - **Spec deviation:** the edit form was built by making `AddRelationshipForm` upsert-capable rather than a duplicate `EditRelationshipForm` (DRY); RTM rows reference `AddRelationshipForm.svelte.spec.ts`. - `api.ts` regenerated from the live spec; only relationship-relevant hunks remain (one springdoc `PageableObject` field-reorder pruned). - **Deploy:** V78 is one-way and not rolling-deploy-safe — stop old JAR → start new JAR (Flyway runs first); targeted `pg_restore -t person_relationships` for rollback. No maintenance window. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

marcel added 6 commits 2026-06-14 19:42:46 +02:00

feat(relationship): add INVALID_RELATIONSHIP_DATES error code ... 47b1ad6199

New 400 error code for a relationship whose toDate precedes its fromDate,
registered in all four sites at once (ErrorCode.java, errors.ts,
getErrorMessage, messages/{de,en,es}.json) per constitution §3.6. Thrown by
the relationship date validation introduced in the following commit.

Refs #837
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

feat(relationship): store from/to as LocalDate + DatePrecision ... 0f6e9f7bc7

Replace person_relationships.from_year/to_year (Integer) with from_date/
to_date (LocalDate) + NOT-NULL from_date_precision/to_date_precision
(DatePrecision, default UNKNOWN), mirroring the Person life-date pattern
(ADR-039 / V76). V78 backfills existing years as YYYY-01-01 at YEAR precision,
adds five named CHECK constraints (coherence both ends, from<=to, precision
value sets) and drops the year columns — verified by RelationshipMigrationTest
on a real Postgres 16 container.

validateRelationshipDates replaces validateYears: coherence (date <=> non-
UNKNOWN precision) -> INVALID_DATE_PRECISION, order (toDate before fromDate) ->
INVALID_RELATIONSHIP_DATES. The derived Zeitstrahl Heirat event now sources the
SPOUSE_OF.from_date at its stored precision, so a DAY-precision wedding surfaces
the exact day instead of just the year. RelationshipDTO and the shared
create/update request (renamed CreateRelationshipRequest ->
RelationshipUpsertRequest) carry the date+precision fields.

REQ-001, REQ-002, REQ-003, REQ-010, REQ-011, REQ-014, REQ-017

Refs #837
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

feat(relationship): add PUT update endpoint, align DELETE mismatch to 404 ... 6d2b6f3d2b

PUT /api/persons/{id}/relationships/{relId} (@RequirePermission WRITE_ALL)
updates a relationship's type, related person, dates and notes in place,
preserving the original createdAt. The update re-runs every create invariant —
self-relation (VALIDATION_ERROR), date coherence/order, reverse PARENT_OF
(CIRCULAR_RELATIONSHIP) and the (person, relatedPerson, type) unique constraint
via saveAndFlush (DUPLICATE_RELATIONSHIP) — and re-flags both endpoints as
family members when edited into a family type. The directed orientation is
preserved per viewpoint, so a PARENT_OF edge stays parent->child whether edited
from either person's page.

Ownership mismatch now returns 404 RELATIONSHIP_NOT_FOUND (shared loadOwned
helper) for both PUT and DELETE — anti-enumeration, replacing DELETE's former
403. No @Version: last-write-wins, matching person edit (single-writer archive).

REQ-004, REQ-005, REQ-006, REQ-007, REQ-008, REQ-009, REQ-012, REQ-013, REQ-018

Refs #837
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

feat(relationship): add formatRelationshipDateRange helper ... 4d9b165a2d

Plain-text "from – to" range formatter for relationship dates, delegating all
precision rendering to the shared formatDocumentDate (zero new precision logic).
Lives in $lib/person next to personLifeDates and reuses the existing
person → shared boundary. From-only renders just the start (no trailing dash),
no dates renders nothing.

REQ-015

Refs #837
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

feat(relationship): date+precision edit UI, notes, and read-view display ... 491d1a015a

Regenerate api.ts for the LocalDate+DatePrecision RelationshipDTO /
RelationshipUpsertRequest and the new PUT, then migrate every caller:

- RelationshipDateField (mirrors PersonLifeDateField: DAY/MONTH/YEAR, 44px
  targets, labelled, semantic dark-mode tokens, relation_* i18n keys).
- AddRelationshipForm is now upsert-capable: an optional `relationship` prop
  pre-fills type, person, both dates+precision and notes; posts to
  ?/updateRelationship (else ?/addRelationship); the submit control disables and
  shows a progress spinner while a request is in flight (REQ-019); notes textarea
  (<=2000).
- RelationshipChip gains an accessible Edit affordance (canWrite + onEdit);
  StammbaumCard wires it, formats the date range via formatRelationshipDateRange,
  and sorts by fromDate. PersonRelationshipsCard (read view) shows the date range
  and notes; no dates -> no date line.
- persons/[id]/edit/+page.server.ts: updateRelationship action (PUT) + the
  addRelationship action reshaped to date+precision+notes (empty date omits
  precision for coherence).
- Genealogy callers fixed for the dropped year fields: familyForest spouse-order
  and StammbaumConnectors ended-edge dashing now key off fromDate/toDate.
- i18n relation_* form keys in de/en/es.

REQ-004, REQ-014, REQ-015, REQ-016, REQ-019

Refs #837
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs(relationship): ADR-044, DB diagrams, deploy runbook, RTM rows ... 663bb57334

- ADR-044 extends ADR-039 to the relationship edge: LocalDate+DatePrecision,
  update re-validation of create invariants, no @Version (last-write-wins),
  DELETE→404 anti-enumeration alignment, precise derived marriage date, and the
  relationshipDates.ts location reusing the existing person→shared boundary.
- db-orm.puml: person_relationships now carries from_date/from_date_precision/
  to_date/to_date_precision; db-relationships.puml gets a V78 columns-only note.
- DEPLOYMENT.md §5: V78 deploy note — no maintenance window, stop-old-then-start
  ordering (not rolling-deploy-safe), targeted pg_restore rollback.
- CLAUDE.md error-code list gains INVALID_RELATIONSHIP_DATES.
- rtm.md: REQ-001..REQ-019 for #837 mapped to impl + tests, all Done.

Refs #837
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

marcel changed title from feat/issue-837-relationship-edit-dates to feat(relationship): editable relationships with LocalDate+DatePrecision dates and notes 2026-06-14 19:44:13 +02:00

marcel added this to the Zeitstrahl — Family Timeline milestone 2026-06-14 19:44:14 +02:00

marcel added 1 commit 2026-06-14 19:48:12 +02:00

Merge remote-tracking branch 'origin/main' into feat/issue-837-relationship-edit-dates ... d9028da941

# Conflicts:
#	.specify/rtm.md

marcel added 4 commits 2026-06-14 20:35:47 +02:00

refactor(person): extract shared DatePrecision coherence/normalize validator ... 73a01b1cad

PersonService and RelationshipService each carried a verbatim copy of the
date⇔precision coherence check and the null→UNKNOWN precision normalizer.
Hoist both into a single document.DatePrecisionValidation util so the rule
that the V76/V78 CHECK constraints mirror has one source of truth. Each
service keeps its own order check (BIRTH_AFTER_DEATH vs
INVALID_RELATIONSHIP_DATES), which is the only genuinely domain-specific part.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

refactor(relationship): collapse add/update onto shared invariant helpers ... a3fd886711

addRelationship and updateRelationship each inlined the same self-check,
reverse-PARENT_OF cycle check, saveAndFlush→DUPLICATE conflict mapping, and
family-membership flagging. Extract them into requireNotSelf,
requireNoReverseParent, persistOrConflict, and flagFamilyMembership so the
shared invariants live once and each public method reads as its own clear
create-vs-mutate sequence. Behaviour-preserving: RelationshipServiceTest (22)
and RelationshipServiceIntegrationTest (10) stay green.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

refactor(frontend): share formatDatePart between life dates and relationships ... 063d1aac55

formatLifeDate and the relationship formatEnd were the same nullable-date →
formatDocumentDate delegation (YEAR fallback, '' on null). Hoist that core into
formatDatePart in documentDate.ts; formatLifeDate becomes a thin glyph-free
alias and formatRelationshipDateRange calls the shared helper directly. The two
range composers stay separate — they genuinely differ (*/† glyphs vs leading
dash). relationshipDates, personLifeDates and documentDate specs (60) stay green.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

refactor(frontend): share DateInputWithPrecision between life-date and relationship fields ... fe1a3dcc00

PersonLifeDateField and RelationshipDateField were the same DateInput + restricted
precision <select>: identical onMount seeding (incl. the YEAR fallback for stored
non-offered precisions), the setCustomValidity partial-date guard, and markup.
Extract that into a domain-agnostic DateInputWithPrecision primitive (caller injects
the precisions, labels, hint, and styling deltas); both fields become thin wrappers
that keep their existing public props, so the person new/edit pages and the Stammbaum
call sites are unchanged. Named to stay distinct from the full DatePrecisionField
(documents/timeline, all seven precisions + RANGE). The relationship select drops its
redundant sr-only label, keeping the equivalent aria-label. PersonLifeDateField,
AddRelationshipForm and RelationshipChip specs (26) stay green.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

marcel merged commit 8558567688 into main 2026-06-14 21:17:38 +02:00

marcel referenced this issue from a commit 2026-06-14 21:17:39 +02:00

feat(relationship): editable relationships with LocalDate+DatePrecision dates and notes (#841)

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

P0-critical

Blocks a core user journey, causes data loss, or is a security/accessibility barrier. Work on this before P1+.

P1-high

Significant friction on a main user journey; workaround exists but is non-obvious. Next up after P0.

P2-medium

Noticeable improvement; doesn't block anything; schedule opportunistically.

P3-later

Cosmetic or parking-lot work; fine to stay open indefinitely.

audit

Read-only audit / assessment work; produces a report rather than changing code

bug

Something isn't working

cleanup

Removal of dead code, vague comments, naming violations, and scratch artifacts

collaboration

We want to extend the family archive to have more collaboration tools

conversation

descoped

We will do that later

devops

documentation

README, ARCHITECTURE, GLOSSARY, CONTRIBUTING, per-domain docs

epic

Marker for epic-level issues that group multiple child issues

feature

file-upload

legibility

Codebase Legibility Refactor — preparing the codebase for human evaluation and bus-factor reduction

needs-discussion

Has an open decision or design question that must be resolved before implementation can start.

needs-review

Spec is drafted and awaiting the multi-persona /review-issue gate.

notification

person

phase-1: security

Security hygiene — must be done first

phase-2: container-images

Production-ready multi-stage Docker images

phase-3: prod-compose

Production compose overlay + Caddy reverse proxy

phase-4: spring-prod-profile

Spring Boot production configuration profile

phase-5: backups

Database and object storage backup strategy

phase-6: deployment-docs

.env.example, DEPLOYMENT.md, runbook

phase-7: monitoring

Prometheus, Loki, Grafana, Alertmanager

refactor

Code restructuring without behaviour change

security

spec-required

Feature whose contract is its issue body (EARS REQ-NNN); the spec must pass review before implementation.

test

ui

UI/UX and accessibility issues

user

No Label

Milestone

No items

No Milestone Zeitstrahl — Family Timeline

Projects

Clear projects

No project

Assignees

Clear assignees

Jens renovate_bot marcel

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: marcel/familienarchiv#841