5b565d5271
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 <noreply@anthropic.com>
55 lines
2.8 KiB
Markdown
55 lines
2.8 KiB
Markdown
# 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.
|