Permissible Operations (Perops)

A Role is a set of Permissible Operations (Perops) which define the operations that can be performed on a given element type.

The hierarchy of Administration elements used in Data Access Control (DAC) is shown below:

When a user is allocated a Role (via an Access Control Rights (ACR)), any update operation performed by the user will have to pass a series of tests defined by the Perops owned by that role. Each test (Perop) may either give permission for the operation to go ahead, deny permission for that operation, or the Perop may not be relevant to that operation.

In order for a user with this Role to perform one of the operations on an element:

• One or more of the Perops in the Role must give the user permission to perform that operation.

  AND

• None of the Perops must specifically deny the user permission to perform the operation. A Perop which denies the user permission will override all Perops whose rules give permission.

  For each Perop, the user defines a list of element types that are controlled by that Perop. The user then define a list of tasks that the user is allowed to perform on those element types. The user may also define a list of tasks that the user is not allowed to perform.

If the Perop allows a Modify operation, the user can additionally specify a list of attributes of the AVEVA base product elements. Permission to change those attributes may be granted or denied by a Perop.

Permission tests are present in all operations that perform detailed transfer of model data, these are:-

• The use of the Output command - used to scan specified parts of the database and output the data in a structure list.

• Export to Review (and other targets accessed via the EXPORT command) - used to identify a list of objects which are reviewed graphically and to define how the objects are to be represented.

• Copy elements between databases - used to copy a single or an element and all its descendents between databases.

  Note:
  A user may have many roles. Only one of these roles needs to gain permission in order for the user to be given access.

  Note:
  In a Global Project Roles and Perops belong to the Global database and cannot be modified at satellites.

In the Element section of the perop the HIER keyword can be used to apply the condition and the operations to an element which is part of a specified hierarchy. For example, using TMPL HIER will include all elements sitting below a template. Therefore a box under a template would be covered by the perop, however a box under an equipment will not be covered by the perop.

The NOT keyword can also be used to apply a perop to everything except the element named. For example using NOT EQUI will apply the perop to everything but equipment. These two keywords can also be combined, for example, NOT TMPL HIER can be used to apply the perop to everything except an item which is part of a template hierarchy. The NOT syntax can also be applied to the attribute column to apply the perop to all but the mentioned attribute. For example NOT LOCK will apply the perop to all attributes but LOCK. The operation does support the addition of multiple attributes or elements, for example NOT LOCK NAME DESC or NOT EQUI TMPL.

The use of lock is particularly important when selectively disallowing modification of attributes. When a perop disallows a particular operation it cannot then be re-allowed in a subsequent perop, restricting the usefulness of the ALL syntax. As such the NOT keyword is used, without this it would be required to add all attributes but the one to be excluded into the attributes column which is impractical.

Note:
The Qualifying Condition Column can be any Programmable Macro Language 1 (PML 1) expression which evaluates to a Boolean, for example, True or False. The user should be aware that any attributes used in the qualifying condition need to be present on all of the elements added to the element list for the condition to work correctly.