Page Comparison

...

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 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.

...

The actions of a permission specify access rights for specific purposes, whereby a distinction is currently made between create access, read access, delete access and write access. The actions can be combined by simply adding multiple actions to the 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 permission to a specific type of object or hide documents that are older than a specific date from a user. 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 function CONTAINS() cannot be used in conditions. Thus, it is not possible to specify a condition on the content of objects to be created.

...

<!-- 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>
    <permission>  <action>create</action>
      <action>create</action><condition>
        <condition> 			system:objectTypeId IN ('appTable:order', 'appEmail:email')
	   	  </condition>
  
   </permission>
  
</role>

...

• Retrieve the tenants role set - GET GET /api/admin/permissions
• Update the tenants role set - POST POST /api/admin/permissions
• Validate the tenants role set - POST POST /api/admin/permissions/validate

For system administrators, the following endpoints are available for managing the global permissions system:

• Retrieve the global role set - GET GET /api/system/permissions
• Update the global role set - POST POST /api/system/permissions
• Validate the global role set - POST POST /api/system/permissions/validate

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 schemasschemata, as the new functionality is meant to exclude any roleset role set entries related to an optional application schema from the main global rolesetrole set.

• Retrieve a global application role set - GET GET /api/system/apps/{app}/permissions
• Update a global application role set - POST POST /api/system/apps/{app}/permissions
• Validate a global application role set - POST POST /api/system/apps/{app}/permissions/validate

To streamline the process of defining yuuvis® Momentum role sets, a number of REST endpoints are made available to retrieve the current role set structures and to apply modifications. As seen in the permissions concept page, there are three options used to structure the role set, coming from two endpoint categories. The /system/permissions and /system/apps/{app}/permissions endpoints are both used to modify the global role set applicable to all users of the system, whereas the /admin/permissions endpoint serves to change the role set specific to the current tenant. 

...