User Groups are defined by Repository Administrators at the repository level. But, Cabinet Administrators can add a User Group to a cabinet. There are three scenarios where an administrator would want or need to add a group to a cabinet:
1. Cabinet Membership - a cabinet's membership consists of those users who can see the cabinet (with the exception of Cabinet Administrators). In order for a user to see the cabinet, they need to be in at least one group that is in this list.
2. Default Access - documents imported or added to a cabinet may receive the cabinet's default access (if no other method is used to apply access). This defines the access rights that will be applied to documents by default. In order for a group to be in the cabinet's default access list, the group will need to be added to the cabinet membership list. Note, access rights are cumulative. This means if UserA is in a group with VS rights, and is in another group with VE rights, then their total access is VES. Or, If UserB is in a group with No Default Access, and is in another group with VESA rights, then their total default access is VESA.
3. UI Access Change - in order for an end-user to apply a group to a document's access control list (ACL) through the UI, the group will need to be added to the cabinet. Otherwise, the end-user will not be able to add that group to the document's ACL. Note, there may also be hidden groups that have been added to the cabinet, but will not be visible to end-users.
Cabinet Administrators can see all groups, or just those added to the cabinet:
For those groups that have been added to the cabinet, the administrator determines the level of access the group has, which becomes part of the cabinet default access list.
There are other areas where groups can be used, but where the user group does NOT need to be added to a cabinet:
4. Groups in ACL - a group can be in a document's ACL even if that group has not been added to the cabinet. In these cases, groups are general put into those ACLs via the API, commonly by ethical walls software. These kinds of groups are generally NOT added to the cabinet membership list because end-users won't be needing to see or use them (#3). Adding a group to a cabinet allows end-users to view and add those groups to documents. End-users cannot manually add a group to a document's ACL through the UI, unless that group has first been added to the cabinet.
5. PBS - when defining profile-based security, the user groups in the access string do not need to be added to any cabinet where those profiles may be used. As long as the group exists at the repository level, the document will receive that group in its access list.
6. ndImport - when defining access for an import, the user groups specified in the import file do not need to be added to the destination cabinet. As long as the group exists at the repository level, the document will receive that group in its access list. In other words, the access string in the import file is validated against the repository, not the cabinet. In most cases, however, these groups will be added to the cabinet membership list as well, for reasons #1-3.
Calculating Access Rights
When a document is accessed by a user, the document's access is calculated to determine the user's final rights. The calculation first checks to see if the user is a member of the cabinet in which the document resides (#1). If not, the user does not have access to the document. Otherwise, the access is calculated based on the user groups listed in the document's access list, whether those groups have been added to the cabinet or not (#2-6).
In other words, a group can be given access to a document, even if that group has not been added to the cabinet where the document resides (the users would have access to the cabinet through some other group, using method #1). But, end-users cannot add a group to a document's access list, unless that group has first been added to the cabinet (#3).
A repository may have up to 350,000 groups in it, but we recommend adding up to only 100 groups per cabinet. The balance of the groups is generally used to silently manage access through an ethical walls software.
In the example below, Client Documents Members represents the users who are members of the Client Documents cabinet (#1) and as such, this makes up the default access list of the cabinet (#2).
In the list at left are those internal groups that have been added to the cabinet. The Demo Group is a member of the cabinet, and was added to the document's ACL through the UI (#3). On the other hand, the Advisor Group is not a member of the Client Documents cabinet, but has still been added to the document's ACL (through PBS, or ndImport, etc.).