Difference between revisions of "Field Permissions"
From SmartWiki
| Line 13: | Line 13: | ||
* ''Whitelisting'' takes the opposite approach - a role, status or type is added to the ''Allow'' setting. | * ''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. | * 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: | + | * 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 | :*''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. | :*''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:56, 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 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
- 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.
