CRM-20091 - Add customValue.gettree api

[colemanw]

This adds a CustomValue.gettree action which returns the entire tree of custom data for a specified entity -
groups, fields, and values, including the raw and display values. It's intended for use on Angular screens that do not have access to core BAO functions like CRM_Core_BAO_CustomGroup::getTree.

• CRM-20091: Case inline custom fields

[totten]

Generally, getTree() has been pretty important, so it makes sense that ends up needing API exposure.

My only real concern is that getTree() has a fairly big surface-area.

• It would be really nice if we could somehow flag the API as experimental.
• Really glad there's a unit-test. Given the surface-area, I'd be inclined to add a little more test-coverage. Some candidates: (a) CustomValue.getfields action=gettree (b) check_permissions behavior (c) just add more random assertions about the returned data.

Those aren't hard-blockers. My opinion is ~1.9/2.0.

[colemanw]

@totten I've pushed some improvements which aren't as scary as they look, I promise. It expands the test coveage with a bit of (a) and (c) per your suggestion, and it also makes the query more efficient by allowing a $toReturn param to be passed into the bao::getTree function. I recycled an old unused param for this, and I think this is safe because 1) I removed all the spots in the code which used it and 2) even if I missed one (e.g. in an extension) that param was always an object, the new param is an array and I added a sanity check to ignore that value if an array isn't passed in.

[totten]

Yeah, CustomGroup::getTree() has been an internal function, so (overall) it seems fair to re-purpose the second parameter. The search/cleanup in civicrm-core seems pretty thorough.

To identify/mitigate impacts on contrib, I grepped universe for CustomGroup::getTree. Pretty much all of them were safe (passing either NULL or CRM_Core_DAO::$_nullObject for the second option). Three files seemed like they should be updated:

• https://github.com/civicrm/civicrm-backdrop/blob/1.x-master/modules/civicrm_engage/civicrm_engage.module#L51-L52 (and a few other lines in that file)
• https://github.com/civicrm/civihr/blob/staging/hrabsence/CRM/HRAbsence/Form/AbsenceRequest.php#L180 (ping @davialexandre )
• https://github.com/civicrm/civicrm-core/blob/master/CRM/Case/Form/CustomData.php#L69

[colemanw]

Ok I've updated that one core line that I had missed, and I sincerely doubt that the backdrop version of CiviEngage is working/tested, but here's this anyway: civicrm/civicrm-backdrop#30

[totten]

Thanks.

I've done some spot-checking in a few random UI's that display custom-data. ("View Contact", "View Contact: Edit custom block", "Edit Profile", "CiviEvent: Edit Event", "CiviEvent: Event Info") They seem to be working the same.

[seamuslee001]

Jenkins re test this please