From 36457f28ff70f9a31b9277aec5cabe0fa085b558 Mon Sep 17 00:00:00 2001 From: Marcel Date: Tue, 2 Jun 2026 20:48:28 +0200 Subject: [PATCH] docs(adr): record the bilateral->unidirectional search regression (ADR-030) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Removing the Briefwechsel view retargets its one inbound link to document search, which filters sender AND receiver — A->B only. The bidirectional "replies" direction is intentionally dropped. ADR-030 records the context, decision and consequences, and notes a bidirectional search filter as the superseding future enhancement. Co-Authored-By: Claude Opus 4.8 --- ...efwechsel-removal-unidirectional-search.md | 54 +++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 docs/adr/030-briefwechsel-removal-unidirectional-search.md diff --git a/docs/adr/030-briefwechsel-removal-unidirectional-search.md b/docs/adr/030-briefwechsel-removal-unidirectional-search.md new file mode 100644 index 00000000..7362ac05 --- /dev/null +++ b/docs/adr/030-briefwechsel-removal-unidirectional-search.md @@ -0,0 +1,54 @@ +# ADR-030 — Removing Briefwechsel trades bidirectional correspondence for a unidirectional search filter + +**Date:** 2026-06-02 +**Status:** Accepted +**Issue:** #716 (remove the Briefwechsel view; retarget its links to document search) +**Milestone:** — + +--- + +## Context + +The standalone **Briefwechsel** view (`/briefwechsel`) was a bilateral letter timeline +between two `Person`s. It was not in the main navigation; its only inbound product link +was the "Häufige Korrespondenten" card on a person's detail page. It was backed by a +dedicated endpoint (`GET /api/documents/conversation`) and two repository queries +(`findConversation`, `findSinglePersonCorrespondence`) that nothing else used. + +The view's data source, `findConversation`, was **bidirectional**: it returned letters +where `(sender = A AND receiver = B) OR (sender = B AND receiver = A)` — i.e. the +exchange in both directions. We removed the view entirely (frontend and backend) and +retargeted the one inbound link into the existing **document search** +(`/documents?senderId=A&receiverId=B`). + +Document search composes its `senderId`/`receiverId` filters with AND +(`sender.id = A` **AND** `receivers contains B`), so the retargeted link shows **only the +A→B direction**. The reverse direction (B's replies to A) is no longer surfaced by +clicking a correspondent. + +## Decision + +**Accept the behaviour change: the retargeted card link is unidirectional (A→B only).** +The reverse direction is intentionally dropped rather than preserved with a redirect +shim or a new bidirectional search filter. + +- The card link sets both params (`senderId=A&receiverId=B`); the destination is the + consistent, already-tested document search rather than a separate dedicated view. +- The "×N" badge on each correspondent chip remains **bilateral** — it counts shared + letters in both directions as a relationship-strength signal — so the badge may exceed + the unidirectional search result count. This is surfaced in the badge's title, not + recomputed. + +## Consequences + +- **Regression:** a reader can no longer reach B→A replies in one click from the + correspondents card. They must run a second search with sender/receiver swapped. +- The bilateral query code (`findConversation`, `findSinglePersonCorrespondence`, the + `/api/documents/conversation` endpoint, and the `getConversationFiltered` service + method) is fully removed — no dormant dead code. +- No data migration and no schema change: only query/endpoint code was removed; the + `documents`, `persons` and join tables are untouched. The `hasSender`/`hasReceiver` + specifications stay — document search still uses them. +- **Future enhancement (out of scope here):** a bidirectional "between these two people, + either direction" document-search filter would restore the dropped direction without + reviving the standalone view. If built, it supersedes the unidirectional link.