There are many places to set Access rights in NetDocuments. One of those places is via your custom Profile Attributes. For example, if you wanted certain users or groups to have access to documents that are profiled with a specific attribute, you can use Profile-based security to accomplish this.
You can enable Profile-based security on a specific attribute by going to "Admin > Define Profile Attributes" and highlighting the attribute and clicking "Edit."
Here, you can click the "Modify Attribute Definition" link at the top-left and make sure the box is checked next to "Base security on this attribute":
Typically, PBS is enabled for the Matter attribute, or the attribute on which workspaces are based.
Once this is enabled, you can then start applying the access rights to the values in your lookup table (Client or Matter list). To add security to a value, locate the value in your table and double-click it. You should now see an "Access" field. This is where you can add your access string.
The syntax for this field is as follows:
[<groupname>|<ACL level>*U:<user email address>|<ACL level>]
An example is given below, with a description for each component:
- The name of a User Group
- A vertical pipe | separates the User (or User Group) from the corresponding access level
- Designates the access level that will be applied. It must be in upper-case.
- An asterisk * separates each individual entry
- An upper-case U followed by a colon U: designates an individual user
- Users are designated by their email address
In the example above, a group called "Litigation" has VES access and the user John Smith has VESA access.
The ACL level (V, VS, VE, VES, VESA, N) always needs to be in all upper-case. The Users and User Groups that you use will need to be valid users/groups in your Repository prior to adding them to the table. The more common profile attributes on which security is based is Matter or Author, but it can also be done for Client, Document Type, or Practice Area. Prior to implementing Profile-based Security you will need to map out your scenario to make sure what you want to implement will work in your environment.
Below is an example of using Profile-based Security in the access column in a .csv lookup table for a Practice Area attribute:
Things to remember when using Profile-based security:
NOTE: Profile-based security is NOT retroactive. Meaning, any access string you put into this field does not automatically update the access of items that have this profile. Conversely, any time you change the workspace's access list, it will not update the access string in this field in the lookup table.
Rights inheritance from folders – If you use Profile-based security, we do not recommend that you check the Cabinet Administration box for "documents to inherit rights from folders". If you do this, whenever a document is moved to a folder, the rights will change to the rights of that folder, even after the Profile-based security rights have been applied.
Cabinet No Default Access – We suggest that when using Profile-based security, that you make the cabinet default for the groups who have access to the cabinet, have either "No default access" or perhaps "View" access. When a Profile-based value is entered for a document, the cabinet default is not removed. If you have set all of the default groups to have "no default access" then any rights they are given using a Profile-based security value will take precedence.
"No Access" Rights - When you give a user or group "No Access" rights for a document or a folder, using the Profile-based security, the No Access will trump any other rights they may have been given.
Absolute Rights - When using Profile-based security as described above, it is "additive" to the cabinet default or whatever the security is currently set to.
In contrast, you can use an absolute security model, which will remove any other ACL entries and replace them with the new absolute security, or only the values contained in the PBS string.
To use absolute security, for a value in your table where you want to use absolute security, precede the entire string with an exclamation mark as follows: !Finance|VES*Legal|V*U:email@example.com|VES.
If the value with absolute PBS is changed to another value, the ACL will also be removed and other values' security may be applied.
This can also be used to prevent users with only View rights from uploading or adding documents to a workspace. Users with absolute V rights will not have the E (edit) rights necessary to add or edit content.
Current User - You can use %CU% in your access string to give the "Current User" access rights. The Current User is the user that you are logged in as when profiling the document. Here is an example: %CU%|VESA
IMPORTANT NOTE: NON-RETROACTIVITY. Profile-based security will not apply to existing documents, Workspaces, or folders. It will only affect items that are profiled after the security is set in the table. To update the profiles of existing documents, you may need to run a Mass Access Change. That is done by making mass changes to the access list of those items: any change will cause the PBS to be applied to those items too.