The Files CMIS API introduces the following features to express the who-shared-what-with-whom relationship on select resources.
|Feature key||Feature value|
|aclHistory||true or false|
This feature introduces the following service operation to the domain model:
- Gets the access control list (ACL) currently applied to the specified document or folder object and for each access control entry (ACE) includes the identity in the system that granted the access right if known by the repository.
- Required inputs:
- ID repositoryId: The identifier for the repository.
- - ID objectId: The identifier for the object
- Optional inputs:
- \Boolean onlyBasicPermissions: See section 2.1.8 Access Control. The repository should make a best effort to fully express the native security applied to the object.
- TRUE: (default value if not provided) indicates that the client requests that the returned ACL be expressed using only the CMIS Basic permissions.
- FALSE: indicates that the server can respond using either solely CMIS Basic permissions, or repository specific permissions or some combination of both.
- <Array> AccessControlEntryType: The list of access control entries of the ACL for the object modified to include the user that granted each right
- Exceptions thrown and conditions:
- See CMIS section 184.108.40.206.1 General Exceptions
- This service must be supported by a repository, if getRepository returns capabilityACL=discover or =manage. How an ACL for the object is computed is up to the repository. A client must not assume that the ACEs from the ACL as returned by this service can be applied using applyACL. In addition, this operation must be supported by a repository for any object type that supports the aclHistory feature key.
This feature introduces the following extensions to the RESTful Atompub Binding:
- http://www.ibm.com/xmlns/prod/sn/cmis/acl-history: Points to the access control history resource for this document.
Parent topic: Files CMIS API features