Smartstaff, administrator
4,478
edits
Changes
no edit summary
SmartSimple's [[custom fields]] can be configured to be visible and /or editable only if certain conditions are met.
On each individual custom field, the following three permission conditions can be set:
* [[Role Field Permissions]]
* [[Status Field Permissions]]
* [[Type Field Permissions]]
* Category Type Permissions: available for Organization Custom Fields.
* Role Type Permissions: available for User Custom Fields.
The first two field permissions, [[Role Field Permissions]] and [[Status Field Permissions]], can also be set on [[standard fields]].
* Each type of Field Permission has ''Deny'' and ''Allow'' settings.
* Adding a role, status or type to the ''Deny'' setting will mean that a contact possessing that role will not be able to see or edit the field; or that if the field is on a record in that status or of that type, it will not be able to be seen or edited.
* This is known in this context as ''blacklisting'' - disallowing visibility or editability based on certain criteria.* ''Whitelisting'' takes the opposite approach - a role, status or type is added to the ''Allow'' setting. This approach means that only contacts possessing a certain role will be able to see or edit the field, or will only be able to see or edit the field if it is on a record in that status or of that type.* The ''whitelisting'' approach is generally preferable to the ''blacklisting'' for scalability purposes: if more roles are added to the system, you will not have to remember to decide whether or not they should have access denied on a set of fields* In line with the rest of the SmartSimple security model, a most-restrictive approach is applied meaning that deny permissions always take precedent over allow permissions. No matter how many allow permissions are satisfied, the field access is restricted if any deny permissions are satisfied.
==See Also==
*[[Batch Update Custom Field Settings]]
*[[Permission Quick Edit]]
*[[Field Permission Matrix]]