There are two mechanisms for controlling access to content in Platform: role based access control (RBAC), and object based access control (OBAC). Role based control operates via the capabilities configured for a user's role and operates on large scale types of content such as documents, portals or collections.
In addition to determining whether a particular user can see each of these types of content, roles also allow control of what types of changes, if any, they are able to make. The capabilities mechanism is described in detail in User roles and capabilities. The rest of this section concerns object based access control.
The following types of content support object based access control:
Projects: access to projects is managed independently from the other content types but the principles are the same.
Worksheet definitions: the collection of columns and their data types that make up a worksheet.
Individual worksheet records: each row in a worksheet has its own access control list.
Folders: each folder can have its own access control list. This does not affect access to the documents in the folder.
Documents: the metadata associated with a document and the list of files that constitute its successive versions
Collections
Collection items: collection items can have their own metadata, and have additional settings to control how access to the underlying document interacts with access to the collection item.
An access control list (ACL) in Opus 2 is simply a list of individual users or groups of users that should be allowed access to the item to which the ACL is attached. In the case of projects, the groups that can be added to the ACL are system level teams. All the other content types exist only within a project. For these types the ACL can include individual users or project level groups.
The ability to use groups in ACLs is important because it allows a single change in one place to modify a user's access to a large number of items in one go without having to modify each ACL independently. When a user is added to a group within a project then they automatically gain access to all items in that project where that group is listed in the ACL. Conversely, removing a user from a group removes their access to all items that they previously had access to solely by virtue of being a member of that group.
Within a project, a user may be in multiple groups and ACLs can contain any combination of individual users and groups. It is therefore possible for a user to gain access to an item via multiple different routes. Any one of these routes is sufficient to grant access to the item. So for example, if a user is removed from a group that has been granted access to certain content, they may still have access to some of that content if they are also in another group that has been granted access.
Even though documents can be arranged in a hierarchy of folders, a user's access to a specific document is independent of whether they have access to its ancestors in the folder hierarchy. This means that it is possible for a user to see a particular folder or document but not to know where it is located in the main folder hierarchy. When viewed on the documents page in platform, such items appear under the "Shared" section below the standard folders tree.
Although the hierarchical position of a document does not directly affect how it is accessed, it can still be useful to think of whole folders being shared with specific users or groups. To this end the user interface provides a number of short-cuts for updating access on a whole set of documents or folders in one go. In particular, when setting access to a folder there is an option to also apply that ACL to documents and folders within the folder. If selected, this causes the ACLs of all items within the folder to be updated, and, depending on the settings chosen in the user interface it may also update the contents of any sub-folders etc down the tree. Similarly, when moving documents there are options for having the ACLs of the documents being moved updated to match the folder they are being moved into. In each of these cases, the final effect is to update the individual ACLs of all the affected items. Access to individual items remains governed exclusively by their own ACL.
There is one exception to the rule that access is defined exclusively by the ACL on an item and nothing else. For documents added to collections, there is an option on the collection item to make the collection item ACL overrule that of the document. When a document is added to a collection a new item is created in the system for the presence of that document in the collection. This captures the position in the collection, any collection numbering applied to it, and potentially any custom metadata fields that apply only to the collection. This collection item can have its own access control.
There is a setting at the top level of each collection to specify how collection item ACLs interact with the ACLs on the documents they refer to. By default, access to the collection item and the document are independent. So a user may be able to see a collection item but not the document it refers to. In this case, they see the full listing in the collection and the numbering is consistent but for some of the items rather than seeing the underlying document they will see a message saying that it is not available.
If however, the collection is set to define access solely on the basis of the collection item, then having access to the collection item grants access to the underlying document even if the user would not otherwise have access to it. This allows, for example, access to certain documents to be granted to particular users on a temporary basis without touching the ACL of the documents themselves. The documents can be added to a collection which is set to grant access to its contents and the collection can be shared with the intended users. Once access is no longer required the ACL on the collection can be updated or the collection can be deleted. This then revokes access, again with no change to the underlying documents.