About the Access Control List (ACL)
You can use the Access Control List to manage the permissions for each object and page defined within your tenant.
Before you can view or modify permissions for any roles, your role must have access to the objects that contain permissions data, and access to the ACL page. The ACL allows you to grant a role full access, custom access, or no access to the objects and pages in your tenant.
After you select an object or page in the ACL, a list of the available roles displays. This list displays any roles that have been created for your tenant. The TenantAdministrator role has full access to all objects and pages in your tenant, and does not display in the list.
The Authenticated User role is also available in the ACL roles list. All users are automatically assigned to this role, which grants basic system access by default. DSI strongly recommends that you do not remove any permissions from the Authenticated User role.
The objects in your tenant correspond to the object definitions in your tenant's database. Granting a role access to an object allows that role to access the data in the corresponding table. If a role is granted permission to execute actions on an object, the users in that role can execute those actions with API calls. The API calls associated with an action can be made directly, from custom pages within modules, or from system pages in the portal. Currently, some objects can only be acted on from custom pages or direct API calls. When setting permissions for objects, keep the following considerations in mind.
-
If you grant a role full access to an object, all users within the role can add, read, modify, search, and update the object. This also allows all users within the role to read and update all fields defined within the object.
-
If you grant a role custom access to an object, you can customize the level of access the role has to each action and field defined for the object. Some fields are required to execute specific actions. For example, if you want a role to be able to add users, you must allow the role to read and update the Loginid field.
-
If you grant a role no access to an object, the users in the role will not be able to access any data for the object. If a user has access to a page that uses the object data, the data will not display.
You can use the page securables in the ACL to define which portal pages a role has access to. When setting permissions for pages, keep the following considerations in mind.
-
Granting a role access to a page only allows the users within the role to view the page itself. The access to any object data within the page must be set from the object.
-
A page may have parents in the menu structure. Before a role can access a page from the menu, it must also have access to that page's parents. For example, you want to grant a role access to the User page. If the User page is nested under Administration > Users, you must also grant access to the Administration page and the Users page.
ACL settings
You can use the Access Control List to modify permissions for each object and page securable defined within your tenant.
Objects
The Objects list contains the system objects, page securables, and assignments in your tenant. After you select an item from the list, you can modify each role's permissions to that item.
For more information on the objects and page securables that are included in each tenant, refer to Objects and securables in the ACL.
Any custom objects and pages in your tenant are also available in the ACL. For information on those items, contact your tenant administrator.
Roles
Displays the roles in your tenant. The TenantAdministrator role has full access to all objects and pages in your tenant, and does not display in the list. For information about roles, refer to About roles.
Permission Access
Displays the level of access each role has to the object or page. You can select Modify to edit the permission level. The following options are available.
-
No Access: The role has no access to the object or page.
-
Full Access: For objects, all users within the role can add, read, modify, search, and update the object itself, and all fields within the object. For pages, all users within the role are granted read access to the page.
-
Custom Access: allows you to customize the level of access.
Custom Permissions
The following custom permissions are available for page securables.
Top Level Permissions
Currently, only the view action is available. This determines whether the role can view the page.
The following custom permissions are available for objects.
Action Level Permissions
Determines whether the role can perform the specified action. You can allow or disallow the execution of each of the following actions.
-
Add: allows the role to add new instances of an object.
-
Read: allows the role to view instances of an object.
-
Modify: allows the role to change the object definition.
-
Search: allows the role to search for specific instances of an object.
-
Update: allows the role to edit instances of an object.
Field Level Permissions
Determines whether the role has access to the specified field. The list of fields is populated from the list of attributes in the selected object. The following permissions can be modified for each field.
-
Read: allows or disallows read access.
-
Update: allows or disallows editing.
Objects and securables in the ACL
You can use the Access Control List to modify permissions for each object and page securable defined within your tenant.
Custom objects and pages
If your tenant contains custom objects and pages, contact your tenant administrator for information on those items. For information on modifying permissions for custom items, refer to Define permissions for a custom object or Define permissions for a custom page.
System objects and securables
The following system objects and page securables are included in all tenants by default.
Users
The following object and page securables allow you to define a role's access to user data.
User Object
Defines whether a role can view or modify user data. For more information, refer to Define permissions for the User object.
The Authenticated User role has read access to the User object by default. DSI strongly recommends that you do not revoke this access.
UserRole Object
Defines whether a role can view or modify the user assignments for a role. For more information, refer to Define permissions for the UserRole object.
Users Page Securable
Defines whether a role can access the Users page in the portal. This only controls access to the page itself. Access to the data within the page is inherited from the User object. For more information, refer to Define permissions for the Users page securable.
If you grant a role access to the Users page, you must also grant access to any parent pages in the menu structure. For example, if the Users page is nested under Administration, you must also grant access to the Administration page.
User Page Securable
Defines whether a role can access the User page in the portal. This only controls access to the page itself. Access to the data within the page is inherited from the User object. For more information, refer to Define permissions for the User page securable.
If you grant a role access to the User page, you must also grant access to any parent pages in the menu structure. For example, if the User page is nested under Administration > Users, you must also grant access to the Administration page and the Users page.
Roles
The following object and page securables allow you to define a role's access to data about the roles in your tenant.
Role Object
Defines whether a role can view or modify roles. For more information, refer to Define permissions for the Role object.
UserRole Object
Defines whether a role can view or modify the user assignments for a role. For more information, refer to Define permissions for the UserRole object.
Roles Page securable
Defines whether a role can access the Roles page in the portal. This only controls access to the page itself. Access to the data within the page is inherited from the role object. For more information, refer to Define permissions for the Roles page securable.
If you grant a role access to the Roles page, you must also grant permissions for any parent pages in the menu structure. For example, if the Roles page is nested under Administration, you must also grant access to the Administration page.
Role Page securable
Defines whether a role can access the Role page in the portal. This only controls access to the page itself. Access to the data within the page is inherited from the role object. For more information, refer to Define permissions for the Role page securable.
If you grant a role access to the Role page, you must also grant permissions for any parent pages in the menu structure. For example, if the Role page is nested under Administration > Roles, you must also grant access to the Administration page and the Roles page.
Modules
Module Object
Defines whether a role can access the list of modules in your tenant. For more information, refer to Define permissions for the Module object.
The Authenticated User role has read access to the Module object by default. DSI strongly recommends that you do not revoke this access.
Countries
Country Object
Defines whether a role can access the list of countries in your tenant. For more information, refer to Define permissions for the Country object.
The Authenticated User role has read access to the Country object by default. DSI strongly recommends that you do not revoke this access.
Languages
Language Object
Defines whether a role can access the list of languages in your tenant. For more information, refer to Define permissions for the Language object.
The Authenticated User role has read access to the Language object by default. DSI strongly recommends that you do not revoke this access.
Permissions
The followings objects and page securable allow you to define whether a role can edit object and page permissions.
Securable Object
Defines whether a role can access the objects in your tenant for which permissions can be modified. For more information, refer to Define permissions for the Securable object.
If you want to allow a role to edit permissions for objects and page securables, they must have access to both the Securable object, and to the Securable Assignments object.
Securable Assignments
Defines whether a role can view or modify the permissions to an object. For more information, refer to Define permissions for the Securable Assignments object.
If you want to allow a role to edit permissions for objects and page securables, they must have access to both the Securable object, and to the Securable Assignments object.
ACL Page Securable
Defines whether a role can access the ACL page in the portal. This only controls access to the page itself. Access to the data within the page is inherited from the Securable object and the securable assignments object. For more information, refer to Define permissions for the ACL page securable.
If you grant a role access to the ACL page, you must also grant permissions for any parent pages in the menu structure. For example, if the ACL page is nested under Configuration, you must also grant access to the Configuration page.
Dashboard cards
User Card Object
Defines whether each user in a role can view and edit the cards on their own dashboard, and add new cards from the list of portal cards. For more information, refer to Define permissions for the User Card object.
Card management
The following object and page securable allow you to define whether a role can manage the cards in your tenant.
Portal Card Object
Defines whether a role can view or modify cards. For more information, refer to Define permissions for the Portal Card object.
Card Management Page Securable
Defines whether a role can access the Cards page in the portal. This only controls access to the page itself. Access to the data within the page is inherited from the Portal Card object. For more information, refer to Define permissions for the Card Management page securable.
If you grant a role access to the Cards page, you must also grant permissions for any parent pages in the menu structure. For example, if the Card Management page is nested under Configuration, you must also grant access to the Configuration page.
Portal
The following objects allow you to define a role's access to the files, components, and pages that make up the portal.
The Authenticated User role has read access to the following objects by default. DSI strongly recommends that you do not revoke this access.
Portal Component Object
Defines whether a role can view or modify the list of React components in your portal. For more information, refer to Define permissions for the Portal Component object.
Portal Page Object
Defines whether a role can view or modify the list of portal pages. For more information, refer to Define permissions for the Portal Page object.
Portal File Object
Defines whether a role can view or modify the list of files in your portal. For more information, refer to Define permissions for the Portal File object.
Menus
The following object and page securable allow you to define a role's access to the menus in your tenant.
Menu Item Object
Defines whether a role can view or modify menu items. For more information, refer to Define permissions for the Menu Item object.
The Authenticated User role has read access to the menu item object by default. DSI strongly recommends that you do not revoke this access.
Menu Management Page Securable
Defines whether a role can access the Menus page in the portal. This only controls access to the page itself. Access to the data within the page is inherited from the menu item object. For more information, refer to Define permissions for the Menu Management page securable.
If you grant a role access to the Menus page, you must also grant permissions for any parent pages in the menu structure. For example, if the Menus page is nested under Configuration, you must also grant permissions for the Configuration page.
Section pages
By default, the following pages are at the top level in the menu structure. You must grant a role access to these pages if you want to grant the role access to any of the page's children. Access to child pages must be granted separately.
If your menus are customized, the above rules may not apply.
Development Page Securable
Defines whether a role can access the Development Studio page in the portal. For more information, refer to .Define permissions for the Development page securable.
Admin Page Securable
Defines whether a role can access the Administration page in the portal. For more information, refer to .Define permissions for the Admin page securable.
Configuration Page Securable
Defines whether a role can access the Configuration page in the portal. For more information, refer to .Define permissions for the Configuration page securable.
Licenses
The following object and page securable allow you to define a role's access to the licenses in your tenant.
License Object
Defines whether a role can view or modify the list of licenses. For more information, refer to Define permissions for the Menu Item object.
The Authenticated User role has read access to the Licenses object by default. DSI strongly recommends that you do not revoke this access.
License Assignments Object
Defines whether a role can view or modify the users assigned to a license. For more information, refer to Define permissions for the License Assignment object.
Licenses Page Securable
Defines whether a role can access the Licenses page in the portal. This only controls access to the page itself. Access to the data within the page is inherited from the License and License Assignment objects. For more information, refer to Define permissions for the Licenses page securable.
If you grant a role access to the Menus page, you must also grant permissions for any parent pages in the menu structure. For example, if the Licenses page is nested under Administration, you must also grant permissions for the Administration page.
Tenant information
Tenant Object
Defines whether a role can access information about your tenant. For more information, refer to Define permissions for the Tenant object.
The Authenticated User role has read access to the Tenant object by default. DSI strongly recommends that you do not revoke this access.
Object models
The following objects and page securables allow you to define a role's access to the object models in your tenant.
Model Object
Defines whether a role can view or modify the list of object models. For more information, refer to Define permissions for the Model object.
If you want to allow a role to edit permissions for objects and page securables, they must have access to the Model Object, the Model Object Reference object, the Definition Object, and the Object Relationship object.
The Authenticated User role has read access to the Model object by default. DSI strongly recommends that you do not revoke this access.
Model Object Reference
Defines whether a role can view or modify the list of object references. For more information, refer to Define permissions for Model Object References.
If you want to allow a role to edit object models, they must have access to the Model Object, the Model Object Reference object, the Definition Object, and the Object Relationship object.
The Authenticated User role has read access to the Model Object References object by default. DSI strongly recommends that you do not revoke this access.
Definition Object
Defines whether a role can view or modify the list of object definitions. For more information, refer to Define permissions for the Definition object.
If you want to allow a role to edit object models, they must have access to the Model object, the Model Object Reference object, the Definition object, and the Object Relationship object.
The Authenticated User role has read access to the Definition object by default. DSI strongly recommends that you do not revoke this access.
Object Relationship
Defines whether a role can view or modify object relationships. For more information, refer to Define permissions for the Object Relationships object.
If you want to allow a role to edit object models, they must have access to the Model object, the Model Object Reference object, the Definition object, and the Object Relationship object.
The Authenticated User role has read access to the Object Relationships object by default. DSI strongly recommends that you do not revoke this access.
Objects Page Securable
Defines whether a role can access the Objects page in the portal. This only controls access to the page itself. Access to the data within the page is inherited from the Model Object, the Model Object Reference object, the Definition Object, and the Object Relationship object. For more information, refer to Define permissions for the Objects page securable.
If you want to allow a role to view or edit the Objects page, you must also grant permissions for any parent pages in the menu structure. For example, if the Objects page is nested under Development Studio, you must also grant permissions for the Development page securable.
Object Page Securable
Defines whether a role can access the Object page in the portal. This only controls access to the page itself. Access to the data within the page is inherited from the Model Object, the Model Object Reference object, the Definition Object, and the Object Relationship object. For more information, refer to Define permissions for the Object page securable.
If you want to allow a role to view or edit the Object page, you must also grant permissions for any parent pages in the menu structure. For example, if the Object page is nested under Development Studio > Objects, you must also grant permissions for the Development page and the Objects page.
Loading...
There was a problem loading this topic