Permission Control Overview

App Level Runtime User Role

First we need to define the User Roles for this app. 

1. On the App List click ‘Trouble Tickets System’ app. 

2. Click the User Role List. 

3. Mouse over the row of Manager and click settings .

This is a generic setting for all the pages and records in this app. Every page, workflow state, and widget can have their own user role permission settings. If they are not specifically in lower levels of permission settings, the privileges that the user can enjoy will follow the “User Role Settings” here. 

Meaning of each privilege 

Run Page:  

Whether the users belong to this role are able to access the page in this app or not 

Read Data:

Whether the users are able to access saved records. 

[All: can read all records; Self: can read records created by the user him/herself; None: cannot read records] 

Save Data: 

Whether the users are able to edit saved records or create new records. 

[All: can edit all records and can create new records; Self: can edit records created by the user him/herself and can create new records; None: cannot create new records or read any records]

Delete Data: 

Whether the users are able to delete records. 

• All: can delete all records

• Self: can delete records created by the user him/herself

• None: cannot delete records

1. For each role, we need to add different users into different roles. Mouse over a user role and click the button to add users and/or user groups. If a user does not belong to any of the user roles, he or she will not be able to find the app icon of this app in the launch board and cannot access this app. 

Let’s know more: 

When a user belongs to more than one user role, and there is a conflict between the roles’ permissions, then the system will adopt the greater permission settings. 

For example, John belongs to “Manager” (Read All; Save Self) and “Mid Manager” (Read Self; Save All), then John enjoys a higher permission setting (Read All; Save All).

Let’s know more: 

You may think that setting the container as No Access and then overriding it in widget level for Start state is a more convenient way. However, according to the Generosity Principle, when the container is set as No Access all the widgets contained will become invisible and cannot be overridden. 

Different Levels of Permissioning 

There are various levels of runtime permissioning available on DragOnce: 

● App User Role 

● Overridden by Page Permission 

● Overridden by Widget Level User Role 

● Overridden by Widget Level Workflow 

● Overridden by Workflow Permission 

Permission Specificity Principle 

When you set permissions at a higher level, the permission settings will apply to lower levels. Overriding will occur only when permission at higher level is more relaxed than permission at lower levels. 

Generosity Principle 

When the permission of the higher level is stricter than that of lower levels, the lower levels will be of a stricter permission. 

For example, when the page permission is set to be “Read None Save None” data and a widget in that page is set to be “Editable”, then the whole page is still invisible. But when the page permission is set to be “Read All” and “Save All” data, and the widget is set to be “No Access”, then the widget will be invisible. 

When a table is set to be “Read Only” for a certain user role, the users therein will not have the “Add+” and “Delete” buttons on the table and thus are unable to create or delete records.