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.

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.

ACL Designer

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.

Creating an new ACL 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 :

Data Modelling

Opening ACL Designer

To open the ACL Designer, enter Config Mode and click on ACL.

Opening ACL Designer

Setting up ACL for a class

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

Example of ACL setup for the Order Class using the OderACL Class as an ACL source

Mode

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.

Storage

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.

Source

The ACL class which is used to store the ACL for the Class X

Credentials

The field of the ACL-Class which is used to store the role id.

Owner (Optional)

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.

ACL Configuration in the Team App

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.

ACL configuration for instances of the Project Class in the Projects app

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 :

Roles & Permissions (Team app)