Address BAO - Handle standard 'custom' param as well as individual fields

[colemanw]

Overview

The Address BAO was an oddball in that it took raw unformatted custom field input and processed it.
Other BAOs expect the custom field input to alreay be processed.
This allows it to handle either format.

Before

Api4 test fails.

After

Api4 test passes

[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]

@colemanw can we add a deprecation notice in the one that is not like other BAO?

[colemanw]

I don't think I'd venture to say that any BAO is exemplary wrt custom field handling. The approach of the Address BAO is IMO smarter, but more verbose and all that boilerplate ought to get moved to a utility function.

[eileenmcnaughton]

@colemanw right & the v3 api handles custom fields within the outer wrapper....

[colemanw]

Yea v4 is handling them in a single point too. But it then expects the underlying BAO to consistently accept an already-formatted $params['custom'], which most do but the Address api did not.

But IMO formatting & saving custom field data is in the domain of a BAO and not an api, so maybe with sufficient unit tests we could do a refactor to make the BAOs more useful and consistent.

[eileenmcnaughton]

right - the problem is we support custom data on ones without BAOs too - so more like a listener almost makes sense.... (punt)

[colemanw]

What's an example of an api entity with no BAO that supports custom fields? I need to make sure Api4 tests cover that.

[eileenmcnaughton]

@colemanw any entity with no BAO - you can have custom fields on any entity (if you add an option_value to cg_extends)

[monishdeb]

Sorry for being late, agree with this patch, tested on APi4 API3 and via UI. Works like a charm