Difference between revisions of "Field Permissions"
From SmartWiki
| Line 19: | Line 19: | ||
==See Also== | ==See Also== | ||
*[[Batch Update Custom Field Settings]] | *[[Batch Update Custom Field Settings]] | ||
| + | *[[Permission Quick Edit]] | ||
*[[Field Permission Matrix]] | *[[Field Permission Matrix]] | ||
Revision as of 10:19, 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 three permission conditions can be set:
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.
