...

...

The permissions to access documents or to perform certain actions are assigned to specific roles. Users of the system are assigned to particular roles, and through those role assignments acquire the permissions needed—they become the owner of the roles. In general, roles are reusable groups of various permissions. Each role has a unique name and contains one or more permissions that are granted to the owners.

Note: In  In the header of each incoming and authenticated API call, the roles of the corresponding user are included among other user-specific information. If you assign too many roles with long names to individual users, you might exceed the overall size limit of 8KB for the header.

Permissions

Permissions denote access rights to certain objects and are assigned to a role. A permission consists of one or more actions and, optionally, a condition. The condition defines which objects are allowed to be managed by owners of a role with the permission, whereas actions define what procedures are allowed upon meeting the condition. In other words if a user tries to access an object, the authorization system will go through that users roles to see if one of the conditions within his permissions is met by the object. If the object meets the condition of one of the users permissions, the user will be able to work with the object according to the actions defined by that permission. 

...

Conditions are statements in the proprietary CMIS-based query language that define the subset of documents in the system affected by a permission. If the condition for a document is met (meaning evaluating the query language expression returns 'true'), the owner of the role gets to access that document. For example, conditions can limit a users access to a specific type of object or hide documents that are older than a specific date. The conditions are appended to all requests from the role owner and thereby act as filters for the corresponding search results. 

Note:

...

In a permission including the

...

action create, the

...

query function CONTAINS()

...

cannot be used in

...

a condition. The whole statement would always be evaluated to false even if the condition contains other sub-statements that do not use CONTAINS() and that would individually considered be evaluated to true. Thus, it is not possible to specify a condition on the content of objects to be created.

The condition can also be left out - indicating that the permission applies to all documents in the system.

The following code block explains the definition of permissions with an example of creation permissions assigned to different roles.

<!-- Users with this role are not allowed to create, update or delete any object. -->
<role>
   <name>CAN_CREATE_NOTHING</name>
</role>

<!-- Users with this role can create any object. No conditions have to be matched. -->
<role>
   <name>CAN_CREATE_EVERYTHING</name>
   <permission>
       <action>create</action>
   </permission>
</role>

<!-- Users with this role can create objects that match the condition. In this case only objects of type 'appTable:order' or 'appEmail:email' can be created. -->
<role>
   <name>CAN_CREATE_SOMETHING</name>
   <permission>
      <action>create</action>
      <condition>
         system:objectTypeId IN ('appTable:order', 'appEmail:email')
   	  </condition>
   </permission>
</role>

...

Since version 2.4, Momentum has the ability to further structure the global role set into applications. This goes hand in hand with the usage of application schemata, as the new functionality is meant to exclude any role set entries related to an optional application schema from the main global role set.

...