CRM-12497 API 'getfields' method returns all custom fields

    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

            [CRM-12497] API 'getfields' method returns all custom fields
            Eileen McNaughton added a comment -

            tests not currently in a state to work on the api

            Eileen McNaughton added a comment -

            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?

            Lola Slade added a comment -

            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?

            Lola Slade added a comment - - edited

            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?

            Eileen McNaughton added a comment - - edited

            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

            Tim Otten added a comment -

            CRM-12497 and CRM-13027 look like the same issue to me – but one is marked as "closed/fixVersion=4.4" and the other as "open/fixVersion=4.5". To determine the actual status, I've added a unit-test:

            https://github.com/civicrm/civicrm-core/pull/1563

              People

              • Assignee:
                Jon K Goldberg
                Reporter:
                Jon K Goldberg

                Dates

                • Created:
                  Updated:
                  Resolved: