You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The relationship chart currently draws a plain connector line between two partners. It conveys that there is a union, but not what kind: you cannot tell at a glance whether a couple is married, divorced, widowed, or unmarried partners. To find out you have to open the family detail page. This is especially confusing in recomposed families where one person has several unions of different kinds.
This is related to #554 (request to show the wedding/union date in the relationship chart) — the same connector is the natural place to surface union state.
Describe the solution you'd like
Render the union status on the relationship-chart connector, derived from the couple's events:
married – marriage event, no later divorce or spouse death
divorced – latest relationship event is a divorce
widowed – one partner has a (dated) death event after the marriage
partners – unmarried / civil-union relationship type
unknown – not enough information
Concretely:
a small marker on the connector per status (e.g. ⚭ married, ⚮ divorced, an open ring for partners, a marker for widowed, plain line for unknown);
a matching status badge on the family detail card.
The status itself is locale-neutral (derived from event types and dates only), so it can be localized in the frontend.
Describe alternatives you've considered
Showing only the wedding date (#554) — useful, but doesn't distinguish divorced/widowed/partner unions. Opening each family page manually — what we do today; doesn't scale on a chart.
Additional context
I have a working implementation and would like to contribute it, split into two PRs:
Backend (gramps-web-api): derive a locale-neutral marital_status (married / divorced / widowed / partners / unknown) and expose it on the family profile, with unit tests. The derivation logic is kept Gramps-free and unit-tested.
Frontend (gramps-web): consume profile.marital_status to draw the per-status connector markers, the optional union-dates toggle, and the family-card badge, with unit tests for the chart helpers.
Opening this issue first per CONTRIBUTING.md to confirm the approach (event-derived status on the connector + optional dates) before the PRs land. Happy to adjust the marker design / wording. PRs to follow and will reference this issue and #554.
Is your feature request related to a problem? Please describe.
The relationship chart currently draws a plain connector line between two partners. It conveys that there is a union, but not what kind: you cannot tell at a glance whether a couple is married, divorced, widowed, or unmarried partners. To find out you have to open the family detail page. This is especially confusing in recomposed families where one person has several unions of different kinds.
This is related to #554 (request to show the wedding/union date in the relationship chart) — the same connector is the natural place to surface union state.
Describe the solution you'd like
Render the union status on the relationship-chart connector, derived from the couple's events:
Concretely:
The status itself is locale-neutral (derived from event types and dates only), so it can be localized in the frontend.
Describe alternatives you've considered
Showing only the wedding date (#554) — useful, but doesn't distinguish divorced/widowed/partner unions. Opening each family page manually — what we do today; doesn't scale on a chart.
Additional context
I have a working implementation and would like to contribute it, split into two PRs:
marital_status(married/divorced/widowed/partners/unknown) and expose it on the family profile, with unit tests. The derivation logic is kept Gramps-free and unit-tested.profile.marital_statusto draw the per-status connector markers, the optional union-dates toggle, and the family-card badge, with unit tests for the chart helpers.Opening this issue first per
CONTRIBUTING.mdto confirm the approach (event-derived status on the connector + optional dates) before the PRs land. Happy to adjust the marker design / wording. PRs to follow and will reference this issue and #554.