Add History Logging for Family Merge and Detach Operations

[vahidbazzaz]

This PR adds comprehensive history logging for family merge and detach operations in the beneficiary management system. Previously, when families were merged or detached (either via action buttons or drag & drop), no audit trail was created in the history table. This made it impossible to investigate cases where beneficiaries (including small children) were unexpectedly deactivated or moved between families.

Changes Made

1. In Manage Beneficiaries add history log if beneficiary is added to a family via drag & drop

• File: include/people.php:503
• Added history logging when beneficiary is added to a family via drag & drop
• Log format: added to family via drag & drop

2. In Manage Beneficiaries add history log if beneficiary is removed from a family via drag & drop

• File: include/people.php:506
• Added history logging when beneficiary is removed from a family via drag & drop
• Log format: removed from family via drag & drop

3. In Manage Beneficiaries add history log if beneficiaries are merged to a family via selection and action button

• File: include/people.php:442
• Added history logging when beneficiaries are merged into a family via action button
• Log format: merged to family (head: [id])

4. In Manage Beneficiaries add history log if beneficiaries are detached from a family via selection and action button

• File: include/people.php:468
• Added history logging when beneficiaries are detached from a family via action button
• Log format: detached from family

5. Drag & Drop Implementation Details

• Files: library/lib/list.php:58-94
• Modified listBulkMove() to track parent_id changes during drag & drop operations
• Returns parent change information to enable history logging

6. Cypress Tests

• Files: cypress/support/database.js, cypress/e2e/1_feature_tests/5_3_Manage_Beneficiaries.js
• Added checkHistoryLog() command to verify history entries exist in database
• Added getBeneficiaryIdFromRow() command to extract beneficiary IDs from DOM
• Created test helper endpoint library/ajax/testhistorycheck.php for test verification
• Enhanced existing merge/detach tests to verify history logging works correctly

Testing

✅ All Cypress tests passing:

• Merge beneficiaries: Verifies history log created
• Detach beneficiaries: Verifies history log created
• Existing tests: All still passing

[vahidbazzaz]

dropapp: add logs to history table if a family has been merged or detached #ciscorsg25

[HaGuesto]

@Vahid I tested this a bit more in depth and would say we need another iteration:

from the functional test:

1. the lastModified date in the people table is somehow not updated could you maybe adapt the definition of the simpleBulkSaveChangeHistory to do this too?

from the code review

• since we do not show the history messages anywhere, I'm happy how they look like atm, but it would be great if you could move the from and to values out of the change message into the right bits of simpleBulkSaveChangeHistory($table, $records, $changes, $from = [], $to = [])
• maybe put "parent_id;" in front in the change message to make clear that the parent_id in the record was changed.

I left comments in the code to make it clearer

[HaGuesto]

this should maybe be simpleBulkSaveChangeHistory('people', $ids, 'parent_id; merged to family', [], ['int'=> <parent_id>);

[vahidbazzaz]

Done in 671650c — now simpleBulkSaveChangeHistory('people', $ids, 'parent_id; merged to family', [], ['int' => $oldest]), so the new family head goes into the to column and the message is prefixed with parent_id;.

[HaGuesto]

this should maybe be simpleBulkSaveChangeHistory('people', $ids, 'parent_id; detached from family', ['int'=> <parent_id>, []);

[vahidbazzaz]

Done in 671650c, with one adjustment to your suggestion: instead of a single call with one from value, the beneficiaries are grouped by their previous parent_id and one simpleBulkSaveChangeHistory('people', $beneficiaryIds, 'parent_id; detached from family', ['int' => $parentId], []) call is made per family. A multi-select detach can span more than one family, so a single shared from would mis-attribute the old family for anyone not in the first group. Same grouping was applied to the drag & drop add/remove paths.

[vahidbazzaz]

Thanks @HaGuesto — addressed all three points in 671650c:

1. lastModified not updating — simpleBulkSaveChangeHistory now runs an UPDATE {$table} SET modified = NOW(), modified_by = :user WHERE id IN (...) after the history insert, guarded by db_fieldexists($table, 'modified') so it's a no-op on tables without that column (e.g. qr). Note this also means the other callers (pdf/qr.php on stock, library/lib/list.php bulk delete/restore) now bump modified/modified_by too — this seemed like correct behavior everywhere rather than a special case, but happy to scope it down with a flag if you'd prefer.
2. from/to out of the message — parent ids now go into the from/to int columns instead of the change string. For detach and drag & drop I group beneficiaries by their old/new parent_id and emit one call per family, since a multi-select batch can span more than one family.
3. parent_id; prefix — added to all family history messages.

Verified locally: 5_3_Manage_Beneficiaries.js passes (merge + detach history assertions), and people.modified/modified_by update as expected.

[vahidbazzaz]

Follow-up correctness fix in d5f5d3d: while verifying the history rows I noticed the merge path was logging the family head as well as the members. Because the head's parent_id doesn't change during a merge, it was getting a parent_id; merged to family row with to_int pointing at its own id (a self-merge). The merge call now filters out the head (array_filter($ids, fn ($id) => $id != $oldest)), so only members whose parent_id actually changed are logged.

Added a checkHistoryLogAbsent Cypress command and updated the merge test to assert the head is not logged while the merged member is. Full spec passes (5/5).