CiviCRM Community Forums (archive)

Issue: when I am in the civicrm_pre or civicrm_post hook I would like to know if an object action originates from the API or from another spot. I need this in case I am using the API for data synchronization. If for example a phone was created I want to know if this creates comes from CiviCRM (and therefore needs to be synchronized) or from the API (and therefore can be ignored as it originates from the other system in the first place).

I just discussed this with Eileen on IRC and we believe the best solution would be to add a context variable to the civicrm_pre and to the civicrm_post hook. The context variable would get a default value of "civicrm". Action would be to change all the calls to the civicrm_pre and civicrm_post hook to have this variable and pass it to the hook.
In the API calling the create function the context would be set to "api". In the actual hook the developer of an extension can then elect to use this variable to do or not do something. I would use it to ignore the synchronization process if the origin is the api.

Does this make sense? Any thoughts on the subject?

I'm in favour of adding a context for these purposes, but don't have strong opinions on the details of the implementation at this point.

I think there may be other uses for this notion of context in the future besides just api or civicrm. In Drupal they have found context to be quite useful as an abstract concept. In other hooks we are using context by other names, eg the form_name or the operation is passed in and generally checked.

At this point it might be useful to allow the context to be passed _in_ from API calls though defaulted to 'api' if not passed. Just a thought.

Issue: when I am in the civicrm_pre or civicrm_post hook I would like to know if an object action originates from the API or from another spot. I need this in case I am using the API for data synchronization. If for example a phone was created I want to know if this creates comes from CiviCRM (and therefore needs to be synchronized) or from the API (and therefore can be ignored as it originates from the other system in the first place).

I'm not sure this inference is valid -- it rests on the assumption that *only* the "other system" makes API calls (i.e. that the core application does *not* make API calls, and that there are no other third-party integrations making API calls). These assumptions may be valid on particular installations (esp. old, vanilla CiviCRM versions), but satisfying those assumptions will be harder in newer/future installations (b/c core code increasingly does call the API -- and b/c third-party modules/extensions are becoming more common).

Joe Murray's suggestion of passing the context designation *into* the API could resolve this -- e.g.

// Make API call
civicrm_api('contact', 'create', array(
  'id' => 3,
  'first_name' => 'Bob',
  'api.context' => array(
    'disable_datasync1 => TRUE,
  )
));

...

// Define the hook
function datasync1_civicrm_post($op, $objectName, $objectId, &$objectRef, $context = NULL) {
  if (isset($context['disable_datasync1'])) {
    return;
  }
  // we're not in a sync context, so send the changes to external service #1
}

Notably, this still works in cases where there are 2 (or 3 or more) modules which all use the same data-sync pattern.

function datasync2_civicrm_post($op, $objectName, $objectId, &$objectRef, $context = NULL) {
  if (isset($context['disable_datasync2'])) {
    return;
  }
  // we're not in a sync context, so send the changes to external service #2
}
function datasync3_civicrm_post($op, $objectName, $objectId, &$objectRef, $context = NULL) {
  if (isset($context['disable_datasync3'])) {
    return;
  }
  // we're not in a sync context, so send the changes to external service #3
}

When service #1 pushes data into Civi, the Civi hooks won't circularly push the data back to service #1; but Civi will push data onto services #2 and #3.

Personally, though, if I were trying to do this (esp. on an older installation), it would seem like a lot of work/risk to get the $context passed through all the possible hook invocations. I'd plug my nose and use a global variable:

// Make API call
global $datasync1_options;
$datasync1_options['disable'] = TRUE;
civicrm_api('contact', 'create', array(
  'id' => 3,
  'first_name' => 'Bob',
));
unset($datasync1_options['disable']);

...

// Define the hook
function datasync1_civicrm_post($op, $objectName, $objectId, &$objectRef) {
  global $datasync1_options;
  if (isset($datasync1_options['disable'])) {
    return;
  }
  // we're not in a sync context, so send the changes to external service #1
}


Along the Tim nose plugin solution this should catch every case of human+browser being the context:

function hook_civicrm_postProcess ( $formName, &$form )) {
$GLOBALS["datasync_from_UIForm"]=$formName;
}

function hook_civicrm_post (...) {
if (array_key_exists("datasync_from_UIForm",$GLOBALS)) {
//needs to be synced because it comes from a form.
}

if (isset($_SERVER['HTTP_X_REQUESTED_WITH']) && $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest') {
//needs to be synced because it comes from an ajax call.
}

}



Erik, could you summarize what you will be taking away from this discussion? Or should we just wait for API v4?

Sounds like a plan. I hope you build in the flexibilty described above, eg by Tim. Is this for CiviBanking?

Okay,
this is what I have just done in some testing for synchronizing phone numbers:

First I added the hook_context param to my specific API, which in turn calls the core API:
$civiparms = array(
"contact_id"        =>  $contact_id,
"location_type_id"  =>  $location_type_id,
"is_primary"        =>  $is_primary,
"phone_type_id"     =>  $phone_type_id,
"phone"             =>  $phone,
"version" =>  3);
        if ( isset( $inparms['hook_context'] ) ) {
            $civiparms['hook_context'] = $inparms['hook_context'];
        } else {
            $civiparms['hook_context'] = "dgwapi.no_sync";
        }
$res_phone = civicrm_api('Phone', 'Create', $civiparms);

Next I have added a  few lines with the hookContext to the CRM/Core/BAO/Phone.php:
  static function add(&$params) {
    $hook = empty($params['id']) ? 'create' : 'edit';
    if ( $params['hook_context'] ) {
        $hookContext = $params['hook_context'];
        unset( $params['hook_context'] );
    } else {
        $hookContext = "core";
    }
    CRM_Utils_Hook::pre($hook, 'Phone', CRM_Utils_Array::value('id', $params), $params, $hookContext);

    $phone = new CRM_Core_DAO_Phone();
    $phone->copyValues($params);
    $phone->save();

    CRM_Utils_Hook::post($hook, 'Phone', $phone->id, $phone, $hookContext );
    return $phone;
  }

I have made a small adjustment to the CRM/Utils/Hook.php:
  static function pre($op, $objectName, $id, &$params, $hookContext) {
      /*
       *
       */
      $hookContextObjects = array( "Phone", "Email", "Address". "Individual", "Organization" );
      if ( in_array( $objectName, $hookContextObjects ) ) {
        return self::singleton()->invoke(5, $op, $objectName, $id, $params, $hookContext, 'civicrm_pre');
      } else {
          return self::singleton()->invoke(4, $op, $objectName, $id, $params, $op, 'civicrm_pre' );
      }
  }

And now I can check in my hook civicrm_pre if a call is from my specific api or from any other spot:

function sync_civicrm_pre( $op, $objectName, $objectId, &$objectRef, $hookContext ) {
    /*
     * only for some objects
     */
    $syncedObjects = array( "Individual", "Organization", "Address", "Email", "Phone" );
    /*
     * only if op is not create (handled in sync_civicrm_post)
     */
    if ( $op != "create" ) {
        /*
         * skip execution if hook originates from API De Goede Woning
         */
        if ( $hookContext != "dgwapi.no_sync" ) {
            if (in_array( $objectName, $syncedObjects ) ) {

What do you think so far? If I am going to tackle this in core I would add the hookContext as an option for the api rather than as a separate param.

Makes sense, I can live with that as a solution.