In AODocs, permissions are applied at the document level:
- each document of a library can have different permissions
- document permissions can also be set by a combination of automatic rules applied by AODocs
- explicit permissions added by the end-users also work.
There are four kinds of permission in AODocs:
- Read: the permission to read a document.
- Write: the permission to modify a document.
- Delete: the permission to delete a document.
- Share: the permission to modify a document's access rights.
The permissions of a document are set by the following rules:
- Library administrators are granted full access (read/write/delete/share).
- If the document has enabled inherited permissions, the permissions of the document’s “parent object” are applied. Depending on the class security configuration (see below for more details), the document’s “parent object” can be either the document’s class, the document’s parent folder, or the document’s current workflow state.
- the specific permissions that are defined on this document are applied.
AODocs combines the three rules above to compute the final set of permissions of each document.
As a general best practice, we recommend to set the document security by relying on the inherited permissions rather than using document specific permissions.
Inherited permissions are powerful to globally set the access rights of a large number of documents with a small number of high level settings.
AODocs provides three different ways to apply inherited permissions to documents:
- Document class permissions, a single set of permissions for all the documents of a document class.
- Workflow permissions, the document permissions are determined by the workflow engine.
- Folder permissions, the document permissions are determined by the document's parent folder.
Learn more: Set workflow permissions
You can configure the inherited permissions in the "Security" tab of your Document class.
Ignoring inherited permissions
Documents and folders can be configured to ignore the permissions inherited from their parent object (document class, workflow state or folder). In this case, the inherited permissions don't apply and the document's (or folder's) permissions are only composed of the library administrators (who always have access to all documents) and the document- (or folder-) specific permissions: ignoring inherited permissions is for example used with folders, to create "private" folders inside of "public folders".