Access Rights can be applied to Focuses, Sub-focuses, Tabs and Forms.
If case when the higher level object is being assigned to the entity (Role, WG or Employee) all its underlying objects (SubFocuses, Tabs and Forms) will be automatically added by the system with the same Access Rights as the Focus. For example, if an Administration Focus is assigned to the Administrator Role in Read-Only capacity, then all Admin Focus’ SubFocuses, Tabs and Forms will be assigned automatically with the Read-Only Rights also. However, explicitly creating a set of Access Rights for of the underlying objects will overwrite the higher object permissions for the underlying Object. For example, Admin Focus Full Control Access Right is given to the User Role System Admin Tier 2. At this point, all Users in this Role will have Full Control rights to ALL objects in Admin focus. Then the Access Right is added for the History Tab with access of READ ONLY. In this case, the Admin Tier 2 Users will have only READ access to the History Tab. If such rights contradict each other due to a mistake made in the Rights assignment or through conflicting assignments from several Roles – the higher access Right will prevail, meaning that READ ONLY will prevail over NONE. Higher Access Right means the less restricted Right.
The following Access Rights for QueWeb UI objects are available out of the box:
• | Not Specified – if permission for some underlying form is not specified then the form will not be visible (no access is granted). |
• | Read – underlying form is visible for the User and User can search/view records via this form (Using Search and Clear buttons but not the NEW and Update). NOTE: This does not propagate to the non-standard buttons that you might create. Please consult with the QueWeb Development Guide to make sure your custom buttons are in synch with User Rights and are included in the Security procedure; meaning that the custom buttons are disabled or enabled corresponding with the User’s effective set of Access Rights. |
• | Write – underlying form is visible and a User can create new or modify existing records via this form; delete is not permitted. |
• | Owner – underlying form is visible and User can create new or modify existing records. User can delete only records created by him/her. |
• | Full Control – underlying form is visible and User can do any operations with the records via the form, including delete operation. NOTE: In some cases the system will prevent Users from deleting certain records, for example if the record being deleted has a linked child records. |
An effective list of access rights is dynamic and managed by the System Administrator. The list can be changed at any time either by changing effective Rights Assignments or creating new objects and setting their Permissions.
|