Access Control Lists (ACL)
This part of the documentation will go through how to set up ACL as an application creator and how to enforce ACLs as a workspace administrator.
Last updated
This part of the documentation will go through how to set up ACL as an application creator and how to enforce ACLs as a workspace administrator.
Last updated
For each application, Access Control Lists (ACLs) can be defined by the application creator to regulates the access to objects of a class using the ACL Designer. Those ACLs can then be used by an administrator to assign access to users base on their role on the platform using the Teams App.
Setting up ACL for a class comes in two steps. First you need to create an ACL class in the Class Designer to store the ACL properties, then head to the ACL designer and configure ACL for your class.
In order to configure the ACL for a class (Class X), a second class (ACL-Class) must be created to store the information about the access to specific objects of the Class A. The ACL-Class must contain the following fields:
a field linked to Class A's ID field with a Data Type uniqueidentifier (referred to as InstanceId field in the documentation)
a field to store the ID of a role with Data Type uniqueidentifier(refereed to as RoleId field in the documentation)
If the ACL class is used for more than one class, a field with the Internal Key RefClassId must be linked to field ID of Class X.
Read more about creating classes using the Class Designer on the following page :
To open the ACL Designer, enter Config Mode and click on ACL.
To setup ACL for a class, first locate the class in the Class column. Next there's 5 parameters you need to configure in the 5 corresponding columns :
Mode
Storage
Source
Credentials
Owner
The Access Control List mode. There are two modes
Restrictable: when creating a new instance of the Class X, an ACL-record for the Everyone role is added by default.
Restrictive: when creating a new instance of the Class X, no ACL-records added. The access to the new instance must be configured by the administrator explicitly or by the owner of the object.
The only storage option available at the moment is External Storage. This is used when the the application creator defines the ACL class which will be used to store ACL records.
The ACL class which is used to store the ACL for the Class X
The field of the ACL-Class which is used to store the role id.
The field of the Class X which stores the Id of the user who is the owner of the instance. The owner can read or change the corresponding instance independently of the ACL.
When ACL is configured for a class in an application, administrators can specify how individual instances of this class are accessed for specific roles in the Team App.
First go to Team App > Groups > Select a group. In the Instances section, select an application and a class for which you want to configure ACL.
In the list of instances of the selected class the administrator can select or deselect individual instances of a class to set if that instance can be accessed for the group or not. For example in the figure above, the group has access to "Test Project 1" but not to "Test Project 2".
The kind of the access is determined by the group rights or the rights that the roles assigned to this group have :
If the group right is Write, the selected instances can be read, created, changed or deleted.
If the group right is Read, the selected instances can only be read.
If the group right is Custom, the access kind (Read or Write) is determined by the rights that application roles assigned to the group.
You can learn more about the Roles and Permissions on the following page :
