Details
-
Type:
Bug
-
Status: Done/Fixed
-
Priority:
Minor
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.4.0
-
Fix Version/s: 4.4.0
-
Component/s: CiviCRM API
-
Labels:None
Description
'getfields' is returning every single custom field, no matter which API you call it on.
In api/v3/utils.php, line 1300, the culprit line is right there:
$fields += _civicrm_api_get_custom_fields($entity, $params);
What's confusing to me is that github says this line existed when we pulled in from SVN on 2/28/13 - but the behavior isn't in 4.3. I'm not too fussed about that; it's just that I don't know who to ask about why it's there!
Attachments
Issue Links
Activity
Jon,
My expectation is that the same thing that broke the tests (not resolving $entity correctly) broke this & fixing the tests probably fixed this - can you confirm if issue persists?
You can see this issue on the demo server still: if you use: http://drupal.demo.civicrm.org/civicrm/api/explorer#/civicrm/ajax/rest?entity=Email&action=create&debug=1&sequential=1&json=1 beside "Available fields (click to add/remove)" you will see several undefined ones.
I am on 4.3 latest git version and I am still seeing this issue. I tracked it down to line 444 of CRM_Core_BAO_CustomField that looks in the cache and returns fields for contacts even when we are doing a getfields for email or any other entity:
$fields = CRM_Core_BAO_Cache::getItem('contact fields', "custom importableFields $cacheKey");
In the case I had under debug the $cacheKey was something like 'Email_0_0_00_7645' but it still returned all the custom fields.
Should I check out master to see if this is still happening or is 4.3 close enough?
I did a bit more checking and the cache table does indeed have those values. I guess the real problem may be the fact that some incorrect fields are being inserted in the cache at line 555 in some cases. A little more info still: It seems that the incorrect values are inserted when $extends is empty on line 529. That in turn seems to happen because $customDataType is not an array so that the segment from line 450-469 never happens. I wasn't sure what the real fix is. Perhaps we can return an empty array of fields if we fail the check on line 387-389? Or perhaps we should turn the argument to an array early on if it is not one?
Lola - if I read you correctly it seems the problem is that
*/
static function getBasicType($subType)
sometimes returns an array & sometimes a string & sometimes NULL which leads to ugliness.
I feel like the function should return a consistent format (array) or problems are bound to arise. If changing that function is too fraught with risk adding a wrapper that is guaranteed to might work e.g getBasicTypeArray - if you went that way you would want to mark getBasicType as deprecated & add adequate code comments
tests not currently in a state to work on the api