CiviCRM Community Forums (archive)

Activity GET API calls based on id field no longer return the same info?

I have code that uses the API to call Activity/get for a given activity Id, requesting custom_13. So the REST version looks like this
/civicrm/ajax/rest?entity=Activity&action=get&debug=1&sequential=1&json=1&return=custom_13&id=683

I used to get back pretty full details including the custom_13 field. Now all I get is:
{
"is_error":0,
"undefined_fields":["id"],
"version":3,
"count":1,
"id":683,
"values":[{
"id":"683",
"source_contact_id":"10"
}]
}
If I do an API call NOT specifying id, but using contact_id, then I get lots of results (obviously) and they do include the custom_13 field as well as other actiivty fields. e.g. (just the relevant entry in the values bit shown:)

"683":{
"source_contact_id":"10",
"targets":{
"10":"10"
},
"id":"683",
"activity_type_id":"45",
"subject":"",
"location":"",
"activity_date_time":"2014-02-28 08:34:00",
"details":"",
"status_id":"1",
"activity_name":"Contract",
"status":"Scheduled",
"custom_13":"12.35",
"custom_13_89":"12.35"
}
}
Is this a bug that's broken the API? Or has there been a change I should know about? It was working in an earlier version (poss 4.3, sorry, can't recall).

thanks.

This had never worked on activities :-( I did hear some murmurring about someone wanting to sponsor this (which would also affect some other entities as well like events & address)

Activity.get has 2 forms
1)  you pass in contact_id & you get what was in v2 api imported into v3
2) since in v2 you HAD to pass in contact_id we put a fall-back to the standard dao-based-get if you didn't.

the activity call has been partially hacked up to retrieve getting custom data at some stage - if you pass in 'return.custom**77__mymotherisamonkey' ('return.custom%') you will get all custom fields returned. This is ugly - it is not using the normal return parameter processing. However, I misunderstood & thought you wanted to filter on custom fields - which doesn't work on dao based api at the moment.

I suggest you add the above parameter to your call -but KEEP the correct call ('return' => array('custom_1', 'custom_2' ) - so if it ever gets fixed you won't notice. Note that 'return.custom_1' will never be unsupported on api v3 - but the thing that could change is that  'return.custom_1' will currently return all 527  custom fields attached to activities.