Creating the Permissions Structure

When setting up a permissions structure for KnowledgeTree in your organization, consider the following:

•	whether users are imported from Active Directory, or from LDAP

•	whether additional user groups will be added within KnowledgeTree, or whether all users are imported from Active Directory/LDAP

•	whether users are logging in remotely

•	whether you are allowing anonymous users to log in

•	whether users must be hidden from each other

Note: In this case, metadata can be added to the fieldsets, instead of displaying client

information. Alternatively, options such as 'email separation by group' may be configured.

•	the importance of security for the organization and its repository

Note: Government agencies are typically expected to be highly secure, and most

organizations own confidential documentation that needs to securely stored and

accessed in the DMS. In both instances, external users should be identified and

prevented from accessing restricted areas of the repository.

•	the importance of permissions for the repository

Note: Permissions may be less important where the system is only used by internal users,

or where everyone requires access to all or most of the content in the repository.

•	whether units and unit administrators are required

Note: Units are useful where the organization prefers to split the administrative role - i.e.

by department, or by geographical regions, for instance. Units are manually created within

KnowledgeTree. They're not supported in Active Directory or LDAP, so they cannot be

imported into KnowledgeTree.

•	whether role-based permissions are required

Note: Roles are a KnowledgeTree concept that are used to allocate permissions on a

document or folder to an individual user. Typically, permissions are granted to the

group, and thus to all users in the group.

•	whether dynamic permissions are required

Note: Dynamic permissions change, based on metadata.