Difference between revisions of "Field Permissions"
From SmartWiki
(→See Also) |
|||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | SmartSimple's [[custom fields]] can be configured | + | 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 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 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== | ==See Also== | ||
*[[Batch Update Custom Field Settings]] | *[[Batch Update Custom Field Settings]] | ||
| + | *[[Permission Quick Edit]] | ||
*[[Field Permission Matrix]] | *[[Field Permission Matrix]] | ||
Latest revision as of 11:30, 11 October 2017
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 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 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.
