CiviCRM Community Forums (archive)

Hi guys,

We are still getting pretty random behaviour on custom fields (some may have been introduced in 3.3 series not quite sure as ... the tests weren't adequate).

Anyway currently a mixture of 'custom_fieldno_valueID' and 'custom_fieldno' are returned. For example participant_get returns

'custom_1' = "I'm a barbie"

But membership returns

'custom_1_34' = "I'm a barbie"

'custom_1' always seems to work for setting the custom fields with the caution that if it's a multi field then it will add an entry whereas 'custom_1_34' will change an existing entry

I suggest that since we don't know whether people are relying on the anomolies & we should be stable we return both on the GET requests. Otherwise we should settle on just 'custom_1'

Hi,

dlobo did mention at one point introducing a name/label to custom fields and use it in the code. I'd personally prefer working with custom_whatever than custom_123. That's one of the issues I have making re-usable modules.

As for the number, definitely having the same convention on all entities is needed. I prefer custom_x.

Side note: when you add/test custom fields, can you check if api.xxx.getfields returns the custom fields ? You probably have to implement the function and return the exportable fields instead of the dao->getfield (check the contact api for example).

X+

dlobo did mention at one point introducing a name/label to custom fields and use it in the code. I'd personally prefer working with custom_whatever than custom_123. That's one of the issues I have making re-usable modules.

yes its on the list, but fairly low down on my list (primarily due to time constraints). ideally we should use something like custom_groupName:fieldName and things are a lot more portable and reusable. Its also a fairly big change across a lot of the codebase, so doing it early in the release cycle would help (so for folks interested in contributing this code, now is an ideal time to do this for 4.1

However we still need to figure out how to modify the protocol to include the custom value id (especially for multiple record values) and make it part of the form. it curently is encoded in the element name as custom_FIELDID_VALUEID

lobo



lobo

Along these lines, we need to think about how to handle multi-valued fields (checkboxes, multi-select, and the like). The most obvious way to input/output them is in arrays. In creating the customValue API, I added the following code to the get function:
    //Convert multi-value strings to arrays
    //TODO: Is this, or should this be, a utility function?
    $sp = CRM_Core_DAO::VALUE_SEPARATOR;
    foreach ($values as &$value) {
      if (strpos($value, $sp) !== FALSE) {
        $value = explode($sp, trim($value, $sp));
      }
    }
Which handily converts all multi-valued results strings into arrays. Since the VALUE_SEPARATOR is added around even single value items (i.e. user only checked one checkbox), the results are nice and consistent (the single checked item will be in a single-item array).  It seems to me that this code should just be added to civicrm_api3_create_success() and then we wouldn't have to worry about individual APIs handling it differently.

Then there's the question of handling input. The inverse of the above code looks like this:
  $sp = CRM_Core_DAO::VALUE_SEPARATOR;
  foreach ($params as &$param) {
    if (is_array($param)) {
      $param = $sp . implode($sp, $param) . $sp;
    }
  }
However, with input it's not quite so simple. The trouble is that API users may assume that they don't need to provide data in arrays if there's only one item. So in the case of a single checkbox being checked, the API is going to need to do a little extra work to ensure that the string gets wrapped in VALUE_SEPARATORs. Again, it would be nice to just add this feature to Api.php so that we are nice and consistent.

Hi,

Yeap, as array in output is fine, as input fine as well but for the json.

for api.contact.get I did do a return=sort_name,email,phone   I am assuming that given that we don't know the content of the multivalue, we are a bit stuck, or can we safely know it won't contain "," ?

Don't know, but potentially an issue for ajax/rest for the input

X+