CiviCRM Community Forums (archive)

I'm trying to build a custom search, and was looking at the Activity search that comes with Civi. It uses various calls to CRM_Core_PseudoConstant to populate details of such as possible activity status or activity type. But in the code comments for CRM_Core_PseudoConstant::activityType() it says "Deprecated - please use  the buildOptions() method in the appropriate BAO object."

I have tried to find some documentation about using buildOptions() but things seem a little sparse. There isn't even much mention of it in the forum. Could someone please explain how I could use buildOptions() to construct a list of activity types (preferably all activity types available to the CiviCase component not just those restricted to contacts directly)?

Thanks

Nick

Here is the documentation:
http://wiki.civicrm.org/confluence/display/CRMDOC/Pseudoconstant+%28option+list%29+Reference

A little background: Prior to 4.4 option lists were sort of floating out in space somewhere, not really connected to anything else. So if for example you wanted to retrieve the option list for a contact's preferred communication method you had to "just know" that the way to get it was by calling CRM_Core_Pseudoconstant::pcm().
Now in 4.4 we're using metadata to "tell" the schema what option list goes with what field. The upshot of that is that all you need is the name of the entity+field and you can get the option list. No secret handshake needed.
CRM_*_BAO_* refers to the PHP object associated with the database table. Generally every table in the database has a BAO class as well as an api method. I think using the api is generally preferred. In the case of getoptions it's just a thin wrapper around CRM_*_BAO_*::buildOptions.
Some examples:
civicrm_api3('contact', 'getoptions', array('field' => 'preferred_communication_method'));
civicrm_api3('contact', 'getoptions', array('field' => 'gender_id'));
civicrm_api3('activity', 'getoptions', array('field' => 'activity_type_id'));

Note that unlike 'pcm' which was just some random nickname that someone conceived, with this new getoptions api we are passing in the actual name of the field that's in the schema.

To use your example below, the reason "activity_type" did not work is because it's not the real name of a field in the civi database (again, like pcm, it's just some random nickname). It may work in the api because someone has defined an alias in the api for some backward-compatability purpose, but "activity_type_id" would work as well and it's the "real" way to do it.

The advantages of using real field names rather than random nicknames:

• You don't have to know any secret words
• It works consistently for every field
• You can write much cleaner code. No need for a bunch of arrays in your code that map field names to pseudoconstant methods.

For example, in my webform_civicrm project I was able to eliminate about 500 lines of code in version 4 that was all dedicated to looking up option lists for fields in all the random different ways it needed to be done. Replaced it all with a single line that looks like:
$options = civicrm_api3($entity, 'getoptions', array('field' => $field_name);