Difference between revisions of "Field Permissions"
From SmartWiki
| Line 1: | Line 1: | ||
| − | SmartSimple's [[custom fields]] can be configured to be visible and editable only if certain conditions are met. | + | 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: | On each individual custom field, the following three permission conditions can be set: | ||
| Line 10: | Line 10: | ||
* Each type of Field Permission has ''Deny'' and ''Allow'' settings. | * 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. | * 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 | + | * 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 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 | ||
| + | :*''security purposes'' - if a certain role is denied access to a certain field, all that is required to see the field would be that the role be removed from their profile, a privilege which in some cases users are granted. | ||
Revision as of 13:55, 26 November 2013
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 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
- security purposes - if a certain role is denied access to a certain field, all that is required to see the field would be that the role be removed from their profile, a privilege which in some cases users are granted.
