Runtime User Roles

Objectives

• Introduce the multiple levels of permission on Dragonce.

• Show some examples to explain the concept of permission.

Permission Overview on DragOnce

Dragonce has multiple levels of permission control, including App, Page, Record and Widget level. The following table illustrates the checking sequence and overriding relationship:

* Please refer to the following section “Run Time User Role and Page Level”.

** Example: If the record is Read Only, the widget can only become No Access in Run Time.

Run Time User Role and Page Level

Runtime user roles are predefined sets of permissions and access rights assigned to different users within an application or system. These roles determine what actions and features each user is allowed to access and perform while using the application. It is typically used to control and restrict certain functionalities based on the user's role or position within the organization. 

Settings screen of Run Time User Role

The following Run Time User Role settings will apply to a record that does not have a workflow or in “Saved” state:

* ”Delete Data” permission cannot higher than “Save Data” permission 

For the Run Time User Role and Page Level permission, the user will be granted the highest permission if he has multiple roles at the same time. The following table shows an example:

If overriding is configured in Page Level, and a user belongs to any user role that is overridden, it will only concern the overridden user role for that user. Similar to the above, the user will be granted the highest permission among the overridden user roles if he has multiple overridden user roles at the same time. The following table shows an example:

Settings screen of Page Settings

Examples

By using the “Admin Panel - Group settings”, You can create a group named "All Staff" that includes all system users. Then, assign this group to the Runtime User Role "Normal Staff". This approach enables simplified user management.

You need to give the new Runtime User Role a name and the Role Privileges of the App pages. 

For example, create a Role Name with ‘Auditor’, give this role ‘ALL’ right to read data, ‘None’ to save data and ‘None’ to delete data. With this setting, all users assigned to the role can read all data but cannot create or delete any data of the app. 

After creating the role, you need to assign a user/user group to the role so all members share the same levels of access and permissions. To assign a user/user group, click on the ‘Add User or Group’ button next to the role.

From the ‘Picker’ window, you can select the users or the groups. Click the ‘Apply’ button to confirm the User or Group assignment. You can use the role in a page/form/workflow after creating and assign the user/group to the role.

To use a Runtime User Role in a page/form, choose the ‘Page Settings’ option next to the page/form from the Page List. From the Page Settings window, you can set the access right of different Runtime User Roles for the page which is overriding the App setting.

To use a Runtime User Role in a Workflow, you can open the workflow, choose the state you need and then choose the Property Setting. For ‘Current Stakeholders’, you can choose ‘Include’ and then choose the runtime user group you want to be the ‘Current Stakeholders’

You could also use the Runtime User Role as the ‘Next Stakeholder’ for an edge of a workflow. Click on the edge and choose ‘Property Setting’, from the option ‘Stakeholders’, choose ‘User Role Mapping’ and then set the default Runtime User Role and the mapping of Previous Stakeholder and Next Stakeholder. 

Checking Sequence of Stakeholders in Workflow State Property Settings and Widget Permission Settings

Edit, Read and Delete Data

The system starts to check the permission of a user by checking tier. It ends until the user matches a relevant stakeholder.

* If a user is referred to multiple settings at the same time, the user will be granted the highest permission.

Settings screen of Workflow State Property Settings (left) and Widget Permission Settings

Widget Permission Settings

For Container or Formatted Container, it tries to apply the permission settings from the container to the widgets inside, unless the widgets have their own permission settings.

Permission settings of the widgets will then override its container, except the container is “No Access”.

Examples

1. The Page permission overrides the Run Time User Role permission

Results: Management cannot access the page.

2. The Widget Workflow Permission further limits the Permission from Record Level

Results: The widget is Read Only as the Widget Workflow Permission further limits the Workflow permission.