CiviCRM Community Forums (archive)

Since CiviCRM 4.2.2 we have the edit-in-place, which I really like. However, I think it also means that I can no longer trust the postProcess hook to catch all my contact updates, is that right? And if that is right, what alternative approach do I have? If my assumption that postProcess does not 'catch' the edit-in-place then I think we are coming to a point where the form related hooks need to be replaced with database action hooks?

I have done a little more testing, looks like most edit-in-place actions actually do call the civicrm_post hook. At least the communication preferences link to the Individual (or other contact types) objectName, the address comes with objectName Address. Adding or deleting an emailaddress or phone however does not do anything, and this is actually what I need for my current project!
The code to call the hook is actually in the BAO code, so I can see
if (!empty($params['id'])) {
      CRM_Utils_Hook::post('edit', 'Email', $email->id, $email);
    }
    else {
      CRM_Utils_Hook::post('create', 'Email', $email->id, $email);
    }
    return $email;When I debug it looks like the code is not executed though...the execution is actually processed by Core/BAO/Block.php and I will do more debugging there. First glance seems to suggest however no call to the CRM_Utils_Hook and no call to the CRM_BAO_Email either.

it also calls the postProcess hook, but for the Inline forms

CRM/Contact/Form/Inline/*.php

lobo

@Eileen, thanks! Made me feel much better (although a warm beer did help too)

1. yes the post hook should also be called in addition to the postProcess hook

2. I'd vote a -1 to do a get on a record before calling the hook. Making yet another DB call for all save operations is expensive and makes things slower. The hook implementor should decide what info they want and make the right DB calls

lobo

Lobo,
the Inline Email does NOT call the postProcess hook as far as I can establish on 4.2.2. Here is my little bit of code that gives me no debug whatsoever:
function silcivi_civicrm_postProcess($formName, &$form) {
if ( $formName != "CRM_Contact_Form_Search_Basic") {

CRM_Core_Error::debug("formName", $formName );
CRM_Core_Error::debug("form", $form );
exit();
}
}
When I delete an email address using the edit-in-place, I do not get to this point.
I have changed the postProcess for CRM/Contact/Form/Inline/Email.php to:
  public function postProcess() {
    $params = $this->exportValues();

    // need to process / save emails
    $params['contact_id'] = $this->_contactId;
    $params['updateBlankLocInfo'] = TRUE;

    // save email changes
    CRM_Core_BAO_Block::create('email', $params);
    // temp Erik Hommel
    CRM_Utils_Hook::postProcess( "CRM_Contact_Form_Inline_Email", $this );

    // make entry in log table
    CRM_Core_BAO_Log::register( $this->_contactId,
      'civicrm_contact',
      $this->_contactId
    );

    $response = array('status' => 'save');
    echo json_encode($response);
    CRM_Utils_System::civiExit();
  }
So it now calls the postProcess hook. I will do the same to my Phone.php. Do you want me to raise an issue and commit these changes?

I agree that the post should be working. The problem is that it is not working for the email and phone either :-) It should if I look at the Block processing but somehow it does not. So if it becomes a core issue, we should really fix it in the Block and get the _post working. I was just doing this as a temp hack because I need the hook to get any further. I will come back to the issue once I have at least a temp solution for the project :-)

If we are going to use the post, which makes sense, we would expect an 'create', 'edit' or 'delete' in the $op parameter, which is not the way in which the Block processing seems to happen. In the Block idea you repace the total picture of phones or emails with the new picture in one go. In theory, that would result in multiple calls of the post hook as it deals with one entity at a time?

Are you sure? Seems to be a pretty suboptimal implementation.

From a user pov (as in, haven't looked at the code might be far away), I'd expect one create for each new phone, or edit for each modified phone and one delete for each deleted phone.

But if the implementation deletes everything, it would be coherent to have n delete followed by n create