marcel/familienarchiv
1
0
Fork 0
Code Issues 119 Pull Requests 2 Actions Packages Projects Releases Wiki Activity

fix(person): flip family_member on both endpoints when a family-graph relationship is added
Some checks failed
CI / Unit & Component Tests (pull_request) Successful in 3m39s
Details
CI / OCR Service Tests (pull_request) Successful in 20s
Details
CI / Backend Unit Tests (pull_request) Failing after 3m45s
Details
CI / fail2ban Regex (pull_request) Successful in 46s
Details
CI / Semgrep Security Scan (pull_request) Successful in 20s
Details
CI / Compose Bucket Idempotency (pull_request) Successful in 1m4s
Details

Browse Source 
The canonical importer creates persons via PersonRegisterImporter first (no family_member
set) and then upserts them via PersonTreeImporter, but mergeCanonical never propagates
family_member to existing persons — so persons with imported relationships ended up
flagged family_member=false and never appeared in /api/persons family filters or the
family-network view.

RelationshipService is documented as the owner of the family_member flag, so the fix
lives there: addRelationship now sets family_member=true on both endpoints whenever the
relation type is PARENT_OF / SPOUSE_OF / SIBLING_OF (the same set getFamilyNetwork
filters by). Non-family types (FRIEND/COLLEAGUE/EMPLOYER/DOCTOR/NEIGHBOR/OTHER) leave
the flag alone — a family doctor isn't a family member. Extracted the type list as a
FAMILY_RELATION_TYPES constant and reused it in getFamilyNetwork for a single source of truth.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
Marcel
2026-05-28 09:15:37 +02:00
parent 9d9cd644ec
commit 07300aeff7
2 changed files with 62 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
backend/src/main/java/org/raddatz/familienarchiv/person/relationship/RelationshipService.java
View File

@@ -31,6 +31,12 @@ import java.util.UUID;
@RequiredArgsConstructor
public class RelationshipService {
// Single source of truth for which relationship types are part of the family graph.
// Consulted by addRelationship (to set family_member on both endpoints) and by
// getFamilyNetwork (to filter the edges returned). FRIEND/COLLEAGUE/etc. are excluded.
private static final List<RelationType> FAMILY_RELATION_TYPES =
List.of(RelationType.PARENT_OF, RelationType.SPOUSE_OF, RelationType.SIBLING_OF);
private final PersonRelationshipRepository relationshipRepository;
private final PersonService personService;
private final RelationshipInferenceService inferenceService;
@@ -64,7 +70,7 @@ public class RelationshipService {
}
List<PersonRelationship> familyEdges = relationshipRepository.findAllByRelationTypeIn(
List.of(RelationType.PARENT_OF, RelationType.SPOUSE_OF, RelationType.SIBLING_OF));
FAMILY_RELATION_TYPES);
List<RelationshipDTO> edges = new ArrayList<>();
for (PersonRelationship r : familyEdges) {
@@ -105,15 +111,23 @@ public class RelationshipService {
.notes(blankToNull(dto.notes()))
.build();
PersonRelationship saved;
try {
// saveAndFlush so the unique_rel constraint violates synchronously and is
// caught here, not at commit time outside the @Transactional boundary.
return toDTO(relationshipRepository.saveAndFlush(rel));
saved = relationshipRepository.saveAndFlush(rel);
} catch (DataIntegrityViolationException e) {
throw DomainException.conflict(
ErrorCode.DUPLICATE_RELATIONSHIP,
"Relationship already exists for (" + personId + ", " + relatedPerson.getId() + ", " + dto.relationType() + ")");
}
// Family-graph edges imply both endpoints are family members. Idempotent: the
// setter is a no-op when the person is already flagged, so re-imports stay clean.
if (FAMILY_RELATION_TYPES.contains(dto.relationType())) {
personService.setFamilyMember(person.getId(), true);
personService.setFamilyMember(relatedPerson.getId(), true);
}
return toDTO(saved);
}
@Transactional