From 2e44cab614a12082266f966957ebe2f34ed69591 Mon Sep 17 00:00:00 2001 From: Marcel Date: Sun, 31 May 2026 15:54:56 +0200 Subject: [PATCH] docs(document): explain the DensityFilters->SearchFilters bridge (#683) Clarify at loadFilteredDates why the density path constructs a SearchFilters: the two filter records are kept separate (density has no date/undated fields), so it adapts here to reuse buildSearchSpec. Raised in the #702 review. Co-Authored-By: Claude Sonnet 4.6 --- .../org/raddatz/familienarchiv/document/DocumentService.java | 3 +++ 1 file changed, 3 insertions(+) diff --git a/backend/src/main/java/org/raddatz/familienarchiv/document/DocumentService.java b/backend/src/main/java/org/raddatz/familienarchiv/document/DocumentService.java index 0f9ac621..faa24de3 100644 --- a/backend/src/main/java/org/raddatz/familienarchiv/document/DocumentService.java +++ b/backend/src/main/java/org/raddatz/familienarchiv/document/DocumentService.java @@ -167,6 +167,9 @@ public class DocumentService { /** Loads matching documents and projects to non-null {@link LocalDate}s. */ private List loadFilteredDates(DensityFilters filters, List ftsIds) { boolean hasFts = ftsIds != null; + // Density and search keep separate filter records (DensityFilters has no + // date/undated fields); adapt to SearchFilters here to reuse buildSearchSpec. + // Date bounds stay null and undated=false — the density path never filters by date. SearchFilters searchFilters = new SearchFilters( filters.text(), null, null, filters.sender(), filters.receiver(), filters.tags(), filters.tagQ(), filters.status(), filters.tagOperator(), false);