====== Record Access Control ====== For more advanced customizations of the permission system and how that compares to Record Access Control look at the [[http://corebos.org/documentation/doku.php?id=en:devel:corebos_permission_hooks|coreBOS Permission Hooks]]. The accepted format is:



  
    22  {optional}
    SalesOrder
  
  
  1  Add button
  1  View record
  1  Edit action
  1  Delete action
  {conditiongroup}  Optional
  
  
  1  Duplicate button
  1  View record
  1  Edit action
  1  Delete action
  {conditiongroup}  Optional
  
  
    
      Invoice
      1  Add button
      1  View list
      1  Edit action
      1  Delete action
      1  Select button
      {conditiongroup}  Optional
    
    .....

where //{condtiongroup}// is



   {cbMapID}
   1  Add button
   1  View list
   1  Edit action
   1  Delete action
   1  Select button

and the business rule must be of type **ConditionQuery** or **ConditionExpression** and return a number bigger than zero, a boolean true, the string 'true' or the string 'yes' to be accepted. Any other value will be false. If the condition is a **ConditionQuery**, the SQL will be executed with only one parameter, which is the CRMID of the Record launching the Record Access Control, if it is a **ConditionExpression** it will be executed with the full set of fields of the Record launching the Record Access Control. The //CRUDS// settings contained inside the will override the default settings if the condition is true. This Business Mapping is tied with the workflow system. Through the workflow system you can assign conditions for the mapping to be applied. For example, we can easily block editing and deleting of a project task depending on the status of it's parent project. That would look like this. First a workflow and business mapping to block the projects that are closed: {{ :en:corebos:businessmapping:racbm_01.png?800 |}} Next a workflow and mapping to block the project tasks: {{ :en:corebos:businessmapping:racbm_02.png?800 |}} You could easily add another condition to the workflows so that they applied only for certain users (for example). =====Condition Query Example===== As an example of the use of a condition query, we could add a rule whereas we permit adding ProjectTask to a Closed Project if the related Account has at least one potential record associated:


 
    
      ProjectTask
      0
      1 
      1
      0
      0

27183
      1
      0 
      0
      1
      1

    
    
      ProjectMilestone
      0
      1 
      0
      0
      0

where the business rule with crmid=27183 is of type conditionquery and contains:



SELECT count(*) as numpots
FROM vtiger_potential
INNER JOIN vtiger_account on vtiger_potential.related_to = vtiger_account.accountid
INNER JOIN vtiger_project on vtiger_project.linktoaccountscontacts = vtiger_account.accountid
INNER JOIN vtiger_crmentity ce ON ce.crmid=vtiger_potential.potentialid
WHERE ce.deleted=0 AND vtiger_project.projectid =?

numpots

=====Block Sent Emails Delete and Edit Example===== Another example is to block editing and deleting of sent emails on the list view, which would be something like this: {{ :en:corebos:businessmapping:racsentemails.png?800 |}} with this mapping:



  
    Emails
  
    
  0
  0

=====Block Tickets if assigned user is not creator===== {{youtube>Iryw1xw78t4}} =====Accessing via web service===== RAC rules must be evaluated on a per Module-Action-Record basis. For each combination of these three values, a search must be made in the workflow system, then each candidate RAC workflow must have its' conditions evaluated, and then, once one is found the map must be read and processed according to the triple given. coreBOS does exactly this process among some other steps in the function **isPermitted** It is this function that we need to call to get the RAC rules in our external applications. This can be easily achieved using a condition expression business map of type function set to isPermitted like this:




	isPermitted
	
		permitted_module
		permitted_action
		permitted_record

which can be called like this:


$response = $cbconn->doInvoke(
	'cbRule',
	array(
		'conditionid' => '37x118348',
		'context' => json_encode(
			array(
				'record_id' => '37x118348',
				'permitted_module' => 'cbMap',
				'permitted_action' => 'ListView',
				'permitted_record' => '',
			)
		),
	),
	'GET'
);
var_dump($response);

You can also call this with the map name. Let's suppose that the map above has the name **RACRulePermittedCheck** you could do this:


$response = $cbconn->doInvoke(
	'cbRule',
	array(
		'conditionid' => 'RACRulePermittedCheck',
		'context' => json_encode(
			array(
				'record_id' => '11x74',
				'permitted_module' => 'Accounts',
				'permitted_action' => 'EditView',
				'permitted_record' => '11x74',
			)
		),
	),
	'GET'
);
var_dump($response);

In general, the idea is:


{
 "conditionid": "RACRulePermittedCheck",
 "context": {
   "record_id": record you want to know the permissions for may be empty (I think),
   "permitted_module": module name of the record you want the permission for
   "permitted_action": the action you want to know the access fo
   "permitted_record": in case the action requires an ID of a record put it here
 }
}