Replaces the previous "depth in generations along the strict
lineal chain" definition (which excluded siblings, aunts, cousins
entirely) with the metric the user actually wants: the number of
descent-steps separating the target from the recipient's closest
direct ancestor or descendant.
Examples relative to the recipient:
- sibling: 1 (parent → sibling)
- great-aunt: 1 (great-grandparent → great-aunt)
- nephew: 2 (parent → sibling → nephew)
- first cousin: 2 (grandparent → aunt → cousin)
- second cousin: 3
- ego, parents, grandparents, ..., children, ..., great-greats: 0
- own spouse, step-parents, brothers-in-law: inherit partner's
distance (so spouse-of-distance-1 is also distance 1)
Implementation:
- Anchor set seeded with R's direct ancestors + R + direct
descendants (capped at 25 generations to bound runaway data).
- Multi-source BFS expanding by descent only.
- Spouse propagation at every level so a person and their
spouse always share the same distance.
- Memoised per (recipient xref, max distance).
Tree preference key and range kept (NEWSLETTER_LINEAL_DEPTH,
0–10, default 3); only the semantics and the user-facing label
+ help text change, with concrete examples in both English and
German.
Per-recipient: only direct ancestors and direct descendants
within a configurable number of generations (default 3) get the
full row treatment (avatar, icon, timeline). Everyone else falls
through to a compact text-only bullet list at the bottom of the
same section.
- New tree preference NEWSLETTER_LINEAL_DEPTH (range 0–10,
default 3) with a clearly-explained admin input.
- RelationshipPathFinder::linealKin() does two cheap recursive
expansions (ancestors and descendants only — no spouse or
sibling traversal) and returns the xref set. Memoised per
recipient within a dispatch run.
- Avatar attachments are filtered per recipient to only the
embeds actually referenced in their HTML, so summary-only rows
no longer inflate per-email size with unused images.
- Recipients with no PREF_TREE_ACCOUNT_XREF (external admin
addresses, users not linked to a record) see the entire
newsletter in detail — no lineal anchor to filter against.
- German translations for the three new section kickers ("Other
birthdays", etc.) and the admin input help text.
Each featured person now carries a parenthetical label relative
to the recipient: "Jane Doe (your mother) — 45th birthday",
"Karl Müller (your 4th great-grandfather) — death". Labels are
italic, muted, and only appear when a path can be computed.
- New RelationshipPathFinder service mirrors webtrees'
RelationshipService::getCloseRelationship BFS but with a
configurable depth (default 14 hops ≈ 7 generations) so it
reaches great-great-grandparents and beyond. Results are
memoised per (recipient xref, target xref) within one
dispatch run.
- nameFromPath() formatting is delegated to webtrees so the
label honours the configured UI language (German, English,
etc.) and gendered/inflected forms.
- The recipient's tree-bound Individual is looked up via
Tree::getUserPreference(user, PREF_TREE_ACCOUNT_XREF). External
admin-added recipients (no webtrees account, no linked record)
silently get no labels — names render plain.
- Trade-off: the view now renders once per recipient (instead of
once per language group), because the relationship map is
personalised. For typical subscriber counts the extra string-
concat cost is negligible compared to the SMTP send itself.
Alexander