CiviCRM Community Forums (archive)

Event participations are mirrored in Activities; when an event participation is deleted, the matching Activity is also deleted.  This makes sense and works fine.

Here's something a little unexpected:

Merge Contact A, who has some events, into Contact B, who has none.  Contact A is the duplicate, and Contact B is the record to keep.  When merging, check the box to "Move related..." Activities, but not move related events.  (Maybe you know all the Event records for Contact A are bogus, but some of the Activity records are good and you want to keep them.)

After the merge, Contact B still has no Participations, which makes sense.  But she does have an Activity for every one of the participations that Contact A had. That's unexpected.

Is this something we'd consider a bug?  Is the solution just to delete those orphaned records from civicrm_activity, or does that cause more problems?  As an admin I could do that as a workaround in hook_civicrm_merge(), but is this something we shoudl address in core?

Thanks,
TM

Hi Lobo,

Looking at the code, it happens that in this case the merge code doesn't specifically process participations at all.  It leaves them alone because they're not selected for moving.  Then when it's done moving all data, it calls civicrm_contact_delete() for the "other" (to-be-deleted) contact, which then goes about deleting that contact's various related data.

One solution might be to do some clean-up of Activity records, within the transaction that happens at the end of CRM_Dedupe_Merger::moveContactBelongings().  We could add some sql statements to that transaction to check for, and delete, orphaned Activities.  I'm guessing this is probably not just for CiviEvent participations; there are probably other components that would be similarly handled, right?

Here's another interesting thing:  That activity that was copied over to Contact B is actually still pointing to a participation record for Contact A.  That activity record is a bit of a mongrel, tied to Contact B in contact_id column, but tied to Contact A via the source_record_id column.  And there of course is no proper activity record for that participation of Contact A.  This will make it pretty hard to restore this record for Contact A if he is ever "undeleted."

Here's an idea: Perhaps we shouldn't be copying activities that are connected to participations (or similar record for other component).  Instead of copying, we could create new Activity records for whatever component records are moved over.  This way we're sure that Contact A's activities are still in order in case of his ever being undeleted, and avoids having activity records for Contact B that don't have matching component records.   This might be done in moveContactBelongings(), since it deals with that related data.

- TM

Yes, probably an edge case. Not too many people will be moving Activities and not moving Events/Registrations. 

But it's good to remember the current behavior does leave corrupted data in the system.  Don't know if there's a cheap fix to prevent that, though.

In my case I can handle it with the hook.

Thanks,
TM