dev/core#2757 test to demonstrate contact delete actions not called for v4 api

[eileenmcnaughton]

Overview

Per https://lab.civicrm.org/dev/core/-/issues/2757 it turns out that our tests were hiding the fact that calling Contact.delete using v4 api wasn't calling the right delete BAO actions (in this case deleting inherited memberships).

This PR just demonstrates this in a unit test

Before

After

Technical Details

@colemanw I thought we had addressed this ?

Comments

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[eileenmcnaughton]

As expected

[colemanw]

Digging in...
This is slightly alarming: evidently APIv4 has never called any BAO::del() methods the way APIv3 did. It has always done its own thing (originally that thing was to call ->delete() directly on a new DAO object, more recently it calls the new DAO::deleteRecords() method, which also circumvents the old del() functions.
This is mitigated by the fact that most of the del() methods don't do very much.

[colemanw]

I want to fix this the right way. And as tempting as it would be, the quick-fix of calling $baoName::del() isn't a good idea IMO. Having skimmed through them just now, some of the del() functions are alarming in their own right!

The end-game here is to have a single generic deleteRecord() function which calls pre/post hooks, and each BAO can register listeners to do their pre/post processing, instead of shoving that logic into del() functions. I'm going to work on something which takes us in that direction as much as possible, while addressing this problem in a reasonable timeframe.

For starters, #21198 #21199 #21200

[colemanw]

Discussion piece for the more complicated del() functions that contain business logic: #21201