Allocating Security Permissions

You can allocate and restrict permissions to each user account and User Group. Every item in the database can have its own set of permissions, or can be set to inherit the permissions that have been set for a parent Group or a Group Instance. The default setting for every new database item is for that item to inherit the security permissions of its parent Group (the Group that contains the item, which is the System or Root group if the item is not within a Group folder).

To allocate the security permissions for an item, you need to log on via a user account that has the Security permission for the item. Of course, the Security feature also has to be enabled on your system.

The permissions that you allocate on the Security window for a database item define which of the item's features are available to the defined users and User Groups. The permissions determine whether a user can access the features for an item, including configuration features, alarms, and controls. By allocating different permissions to different users and User Groups, you can restrict system activities.

Any item that does not have its own ACL configured (for example, a new item) will automatically inherit the ACL of its parent Group. If you want to configure an item so that it has a different ACL to that of its parent, you have to clear the Inherit Permissions from Parent check box on the Security window. The Inherit Permissions from Parent check box is selected by default, as items have the same security settings as their parent Group or the System group when they are first created.

To configure an independent ACL for an item or Group, you have to clear the Inherit Permissions from Parent check box for that item or Group. Then you can use the Permissions check boxes to configure the ACL as required.

When configuring the security permissions for a Group, you can choose whether the ACL overrides the ACLs for the items in the Group by using the Remove Explicit Permissions on Descendants feature. When you select the Remove Explicit Permissions on Descendants check box, the ACLs of the items in the Group are removed, causing the items to inherit their security permissions from the Group.

The following example illustrates how Permissions can be allocated for Group items to manage how User accounts and User Groups access various items within the database.

Example:

This example illustrates how permissions might be allocated using User Accounts and User Groups. A typical system might contain the following set of User Groups. The 'Everyone' User Group is a built-in group.

A typical system might contain the following set of User Accounts that encompass Engineers, Operators and System Administrators.

Allocate User Group Permissions in the ROOT Group

Using the User Groups you can configure permissions for a typical system. In order to configure permissions for a User Group at any level within a system you must configure at least the minimum of permissions for that User Group in the ROOT Group.

The ROOT Group permissions for the User Groups might look similar to those shown below.

When you are allocating permissions, remember that the permissions that are allocated to the Guest user are available to anyone. Also, the permissions that you allocate to the 'Everyone' User Group are allocated to every user account automatically (including the Guest user account). The permissions that you allocate to the Web User are allocated to anyone that accesses the system via Original WebX. By default on new installations, the Guest user has no access permissions, and the 'Everyone' User Group is inactive and not assigned any permissions. We recommend that you leave the Guest user and 'Everyone' User Group at these defaults unless they are genuinely required. In which case, you MUST configure them to have the minimum appropriate permissions and access that are required, such as setting the Guest, Everyone, and Web permissions to Read only on just the required section of the database. To allow your system users access to items and features, you should create 'configured' user accounts and User Groups. This provides greater flexibility and control over the functionality and features to which individual users, or groups of users, have access.

Allocating Permissions to a Group Item

You can now allocate permissions to a Group Item, for example Group 1. If you require the same permission settings as the ROOT, you can set the Permissions to be inherited from the ROOT.

Allocating Permissions for Specific User Groups

The following Group A and Group B groups only require permissions for Group A Operators and Group B Operators respectively. For these Groups you need to customize the permissions.

Allocating Permissions to Manage User accounts and User Groups

On most systems the management of user accounts is the responsibility of System Administrators. Using Permissions you can restrict access to the User accounts and User Groups to System Administrators.

In addition, you can also restrict the configuration of security settings so that only users with system administration knowledge or training can access the Security window.

In ViewX, it is possible for a user to have the permission to access a feature for a database item but still be unable to access the feature. This is because in ViewX a user can only access an item's feature if the item's security settings grant the relevant permissions to the user and the ViewX feature is enabled for the User.

A similar situation can occur when the Permission Restrictions settings are in place. The Permission Restriction settings override other security features and allow you to prevent just ViewX users, just Virtual ViewX users, or all system users from having access to certain features irrespective of their user account permissions. To access a feature, your user account has to have the relevant permission and that permission has to be unrestricted by the server’s Permission Restrictions settings (see Use Server Side Permission Restrictions).

Further Information

Organize your Users and User Groups.