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 permissions 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, and share).
- If the document has enabled inherited permissions, the permissions of the document’s “parent object” are applied. Depending on the security configuration of the document class, the document’s “parent object” can be:
- the document class
- the document’s parent folder
- the document’s current workflow state
- The specific permissions defined on this document are applied.
AODocs combines the three rules above to compute the final set of permissions of each document.
As general best practice, we recommend that you set the document security by relying on 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 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 settings.
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 composed of:
- the library administrators (who always have access to all documents)
- the specific permissions on documents and folders
Ignoring inherited permissions can be used, for example, to create "private" folders within "public" folders.