Permissions

Permissions are granted to any object in a model tree by using Profile objects from the Access Model. Different Profiles can be assigned to the same local Window user/group account by creating User Identifier objects for the same account underneath all the respective Profile objects (directly or indirectly underneath Group Identifier objects).

To assign a Profile to an object, a Security Reference is created by dragging & dropping a Profile object onto the References property compound of the specific object.

Permissions that can be granted are:

  • List: Object will appear when listing the parent’s children

  • Read: All object properties can be read.

  • Write: The current values of the object can be written.

  • Modify: All object properties can be written.

  • Execute: The object’s methods can be called.

  • Inheritable: The explcitly set permissions are inherited by all child objects.

When permissions are specified, all permissions which are NOT granted are effectively revoked.

Effective Permissions

The Effective Permissions granted for a Profile are based on Explicit and Implicit Permissions.

Explicit Permissions

Explicit Permissions are permissions that are assigned to directly to an object. Explicit permissions only apply to the object for which the security reference was created.

Implicit Permissions

Implicit Permissions are permissions which are not specifically set for an object but are granted from another object. These are granted when the List and/or Inheritable permissions are explicitly assigned to an object.

The List and Inheritable permissions assign implicit permissions in different ways:

  • Implicit Permissions propagated to Descendants (Normal): When the object is explcitly assigned the Inheritable permission for a specific profile, all of its descendant objects will be implicitly granted the same permissions as this object until the inheritance is interrupted by an object which has an explicit set of permissions where the Inheritable permission is not enabled.

    For example, if a parent object is assigned the Read, Modify and Inheritable permissions for a specific profile, the profile will have permission to read and modify the parent object AND permission to read and modify all of its child objects that do not have explicit permissions defined.

  • Implicit Permissions propagated to Ancestors (Ancestral): When an object is explicitly assigned the List permission for a specific profile, its ancestor objects (from the parent object up to the root of the tree) are implicitly granted the List permission, allowing them to be viewed in the model tree. If any of the ancestor objects have explicit permissions that do not include the List permission, these objects will not be implicitly granted the List permission.

    For example, if a child object is assigned the Read, Write and List permissions for a specific profile, then this profile will have permission to read and write to the child object. This profile will also have the permission to view the parent object in the tree hierarchy but will not be able to read or write to the parent object.

Rules for Effective Permissions

The system determines the permissions for each object using the following rules:

  • Any explicitly granted permissions will override ALL implicitly granted permissions.

  • Explicit and implicit permissions are not merged in any way

  • Normal implicit permissions will override ancestral implicit permissions.

  • Implicit permission propagation can be stopped by explicit permissions.

  • Permissions are determined from top to bottom in the model tree.

Effective Permissions Example

In this example, the parent object, Object A, has a Security Reference explicitly setting LRW––I permissions. Due to the Inheritable permission being granted, these permissions are passed on to its descendants - as shown in Object B, Object B1, Object E and Object E1. For these objects, these are implicit permissions.

Object C would also inherit the permissions from Object A but has a Security Reference on its own, setting –R–––I permissions explicitly. This Security Reference replaces all implicit permissions which otherwise would have been inherited from the parent object. Due to the Inheritable permission being granted, the new permissions for Object C are again passed on to its descendants, here Object C1.

Object D also has its own Security Reference. In this case, Read and Write permissions are explicitly granted, all other permissions being effectively revoked. Since the Inheritable permission is not granted, the descendants of Object D are cut off from any heritage provided by their ancestors.

Object E, being a descendant of Object A with no Security Reference on its own and no object in between affecting the permissions, inherits the permissions from Object A.

Permission Inheritance

Legend
Security References are exclusive! Once such a reference is created for an object, only the referenced Profile can access this object - according to the granted permissions. For other Profiles to be able to access the same object, additional Security References need to be created on this object explicitly.