Hooks in nested actions

Nested actions differ from primary actions in that action access control hooks and notification hooks are not executed for nested actions.

The Action Access Control hook is not run if a hook starts a nested action. Because all hooks execute with the SuperUser privilege, the privilege level is already at its highest (SuperUser). There is no need to run the access control hook for the nested action.

Access for a nested action is also granted when no access control hook is fired.

Notification hooks do not execute for a nested action, by default. Notification hooks are used to send an e-mail. Having each nested action send an e-mail would result in many e-mails sent for what the user considers to be one action. You can override this behavior and allow nested actions to execute notification hooks by setting the CQHookExecute session variable to a value of 1.

Setting the CQHookExecute session variable can be done with the following code:

• VBScript:

  
    dim session
  
    set session = GetSession
  
    session.NameValue "CQHookExecute", 1
  

• Perl:

  
    $session->SetNameValue("CQHookExecute","1");
  

Within a Commit hook, the commit at the database level is not done when the nested action is committed, but is combined with the outer level commit so that all changes are included as one atomic transaction.

In all other hook types, a nested action is committed at the database level, independent of the outer level commit. The only way to combine changes made in a nested action with those of the top-level action, as a single database transaction, is to have the nested action inside a Commit hook.

See the HCL Compass Schema developer online help for more information on execution order of hooks and when a record is committed. For setting field values, see the SetFieldValue method of the Entity Object.