Import task delete permissions change

[JasonWildMe]

Adjusts ImportTask delete permissions to be strictly limited to:

• admin
• orgAdmin for import task owner
• import task owner

Also ensures Relationship objects are deleted along with bulk import if the related MarkedIndividual is also deleted during bulk import delete.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 47.21%. Comparing base (5dcae11) to head (72e550f).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1444   +/-   ##
=======================================
  Coverage   47.21%   47.21%           
=======================================
  Files         272      272           
  Lines        9720     9720           
  Branches     2862     2944   +82     
=======================================
  Hits         4589     4589           
+ Misses       4900     4895    -5     
- Partials      231      236    +5     

Flag	Coverage Δ
backend	47.21% <ø> (ø)
frontend	47.21% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[JasonWildMe]

@claude

[claude]

Claude finished @JasonWildMe's task in 1m 49s —— View job

---

Code Review

• Gather context and read changed files
• Review code changes
• Post review feedback

---

Summary

This PR makes two changes to ImportTask.java:

1. Replaces the broad Collaboration.canUserAccessImportTask permission check with a stricter, explicit access control model
2. Adds Relationship cleanup when a MarkedIndividual is deleted during import task deletion

---

Permission Change (lines 496–501)

Old behavior — Collaboration.canUserAccessImportTask granted delete access if the user could access any single encounter in the import task (via collaboration), which is overly permissive for a destructive bulk-delete operation.

New behavior — explicitly limits delete to:

• admin role
• Import task owner (by user ID)
• orgAdmin who shares an organization with the task's creator

This is a clear improvement. A few observations:

Ownership check uses ID comparison (user.getId().equals(...)) — this is more robust than the previous username comparison in canUserAccessImportTask, since usernames can change.

isOwner and isOrgAdmin both guard against null creator — correct, but if creator is null, neither isOwner nor isOrgAdmin will be true, so only admins can delete ownerless import tasks. This seems intentional but worth documenting with a comment if not already obvious to maintainers.

isOrgAdmin correctly scopes to shared organizations — the getAllCommonOrganizationsForTwoUsers check ensures an orgAdmin can only delete tasks from users in their organization, not arbitrary users.

---

Relationship Deletion (lines 539–545)

ArrayList<Relationship> rels = myShepherd.getAllRelationshipsForMarkedIndividual(mark.getId());
if (rels != null && rels.size() > 0) {
    for (Relationship rel : rels) {
        myShepherd.getPM().deletePersistent(rel);
    }
}

mark.getId() is correct here — MarkedIndividual.getId() returns individualID, which matches the markedIndividualName1/markedIndividualName2 fields queried in getAllRelationshipsForMarkedIndividual. Confirmed consistent with the existing call at MarkedIndividual.java:2024.

Placement is logical — relationships are cleaned up before social unit membership removal and before throwAwayMarkedIndividual, which is the right order.

Minor style note: getAllRelationshipsForMarkedIndividual always returns an ArrayList (never null), so the rels != null guard is technically unnecessary. Not a bug, just slightly redundant. Could also use !rels.isEmpty() instead of rels.size() > 0.

---

Overall

The logic is sound and the changes achieve the stated goals correctly. The permission model is more intentional and secure than what it replaces, and the relationship cleanup correctly handles orphaned Relationship objects using the right identifier. No functional issues found.