This is an old revision of the document!
Business Actions are things that can happen inside the application. They enhance the vtiger CRM link system and they can affect any part of the application.
They are shown/applied depending on the field permission values set on each record which may include conditional business maps.
By default, each action will be applied to all modules. We can make an action apply only on certain modules using the Only On My Module checkbox combined with the desired modules being selected in the Modules select box.
The permission system will permit us to:
They can be retrieved via the getBusinessActions web service method.
Developer Blocks are a very powerful way of adding custom functionality into coreBOS. With them, we can easily create all sorts of scripts with any functionality we need, but sometimes we just want to launch a script or method and get a result message back on screen. To accomplish this we can create a business action that calls runBAScript. This function accepts a URI to call and expects one of three responses:
For example, if we create a script named write2log.php inside the Accounts module we could create this Business Action:
javascript:runBAScript('index.php?module=Accounts&action=AccountsAjax&file=write2log')
and write2log.php could be:
<?php require_once 'vtlib/Vtiger/Module.php'; require_once 'Smarty_setup.php'; global $log; $log->fatal('write '.$_REQUEST['__module'].' - '.$_REQUEST['__crmid']); $smarty = new vtigerCRM_Smarty(); $smarty->assign('ERROR_MESSAGE', 'write '.$_REQUEST['__module'].' - '.$_REQUEST['__crmid']); echo '%%%MSG%%%'.$smarty->fetch('applicationmessage.tpl');
As can be seen in the previous script the URI called will always receive two additional parameters:
In order to make it even easier to add functionality inside coreBOS with business actions, you can also launch a workflow from one. This opens the possibilities enormously as almost anything that can be done from a workflow can be done from a business action link.
Note that this will only work correctly when we can pass in a unique CRMID (or list of CRMIDs), as the workflow system requires a record to be able to get its context of execution.