Friendly app-level validation for a RANGE with end-before-start #678

New Issue

marcel · 2026-05-27T12:39:57+02:00

marcel commented

2026-05-27 12:39:57 +02:00

Context

Follow-up surfaced in the review of PR #677 (Phase 4 date rendering, #666) — Sara (QA).

A document with meta_date_precision = RANGE must have meta_date_end >= meta_date. This is already enforced at the database layer by the CHECK constraint added in the V69 migration (#671), so an invalid range cannot be persisted — but the application currently has no friendly validation: an end-before-start edit fails with a raw DataIntegrityViolation rather than a clear field-level error.

Suggested approach

Add app-level validation in the document update path (or DocumentUpdateDTO) that rejects meta_date_end < meta_date for RANGE precision with a clear ErrorCode + localized message, before it reaches the DB.
Mirror the message in the edit form (WhoWhenSection) so the user sees an inline error.

Out of scope / notes

Correctness is not at risk today — the DB CHECK is the backstop. This is purely a UX improvement (better error than a 500).
Server-side range validation was explicitly deferred from #677 to keep that PR presentation-focused.

## Context Follow-up surfaced in the review of PR #677 (Phase 4 date rendering, #666) — Sara (QA). A document with `meta_date_precision = RANGE` must have `meta_date_end >= meta_date`. This is **already enforced at the database layer** by the `CHECK` constraint added in the V69 migration (#671), so an invalid range cannot be persisted — but the application currently has **no friendly validation**: an end-before-start edit fails with a raw `DataIntegrityViolation` rather than a clear field-level error. ## Suggested approach - Add app-level validation in the document update path (or `DocumentUpdateDTO`) that rejects `meta_date_end < meta_date` for RANGE precision with a clear `ErrorCode` + localized message, before it reaches the DB. - Mirror the message in the edit form (`WhoWhenSection`) so the user sees an inline error. ## Out of scope / notes - Correctness is **not** at risk today — the DB CHECK is the backstop. This is purely a UX improvement (better error than a 500). - Server-side range validation was explicitly deferred from #677 to keep that PR presentation-focused.

marcel added the P3-later feature labels 2026-05-27 12:40:13 +02:00

marcel referenced this issue

2026-05-27 12:44:03 +02:00

feat(dates): honest precision-aware date rendering (Phase 4, #666) #677

marcel referenced this issue

2026-05-27 12:44:36 +02:00

feat(dates): honest precision-aware date rendering (Phase 4, #666) #677

marcel referenced this issue

2026-05-27 12:45:31 +02:00

feat(dates): honest precision-aware date rendering (Phase 4, #666) #677

Sign in to join this conversation.