Financial items aren't updated, resulting in deletion

MegaphoneJon commented 5 years ago

To replicate:

Create a record "John Doe".
Create a second record "John Q Doe".
Add a contribution to John Q Doe.
Run the following SQL: SELECT * FROM civicrm_financial_item ORDER BY id DESC LIMIT 1;. Note the correct financial item.
Move the contribution to John Doe.
Run the SQL again. Note that the contact ID still belongs to John Q Doe.
Delete John Q Doe permanently.
Run the SQL again. Note that the financial item is completely gone.

This is because there's a foreign key (with cascading delete) on the contact_id field in civicrm_financial_item. There is a check in place to prevent deleting a contact with a contribution - but not a contact with a financial item and no contribution.

If, instead of moving the contribution and deleting it, you merge the two contacts, the contact_id on the financial item is updated. This is, I believe, the correct behavior.

MegaphoneJon commented 5 years ago

Looking through how Dedupe code handles it, I also wonder what the correct behavior is if the contribution is tied to a pledge, membership or participant record. I'm leaving that out of scope for now though.

lcdservices commented 5 years ago

Good find. I'll work on a fix.

Re: linked entities -- we don't touch them (on purpose). So if a contrib is linked to a membership, moving it will retain the link to the membership. That's useful in a case where you have a membership created and then later find that someone else will be paying for it, thus the need to move the contribution but keep the membership attached to the original contact.

lcdservices commented 3 years ago

fixed with version 2.1

lcdservices / biz.lcdservices.movecontrib

Financial items aren't updated, resulting in deletion #2