Using Status Control with Data Access Control

Status Control can be tightly coupled with Data Access Control (DAC) to preserve data integrity. Below are some examples of what can be achieved. They have been created on the basis of Roles where the first PEROP grants all rights on all element and attribute classes, and then successive PEROPs deny some rights under specific conditions.

The following section lists examples for using Status Control with Data Access Control (DAC).

Example to Prevent Modification of an Object of a Certain Status

This is to prevent changes to an object once it has reached a level of completion.

Create a PEROP that denies modify and delete operations on equipment for all attributes once the Design Status is greater than or equal to 50%. Here is the condition to use.

COND ( ATTRIB STVNUM(ID /DesignStatus ) GE 50 )

A suitable error message would be: "DAC: You may not modify object that has status Work Completed".

Example to Catch When the Dictionary Database Has Been Deferred

This traps the situation where a User has tried to defeat the access control by deferring the dictionary Database (DB) containing the status definitions.

Create a PEROP that denies modify and delete operations on equipment for all attributes if the Design Status is not a valid reference. Here is the condition.

COND ( NOT UNSET ( ATTRIB STVUNR ) )

A suitable error message would be: "DAC: You may not modify an object with an unresolved status".

Example to Prevent Change of Status After a Certain Level

This is to allow a User to move an object into a For Check state but prevent them from moving it out. A more privileged User will have the task of promoting it to Checked.

Create a PEROP that denies modify and delete operations on STALNK (status link) elements for attribute VALREF (status value reference) if the current value of Design Status is For Check. Here is the condition.

COND ( ATTRIB OWNER OF VALREF EQ ID /DesignStatus AND ATTRIB DESC OF VALREF EQ 'For Check' )

A suitable error message would be: "DAC: You may not change the Design Status of this object as it is awaiting Check".

Example to Prevent Removal of Status from an Object

This is to prevent a User from removing status from a controlled object.

Create a PEROP that denies delete operations on STALNK (status link) elements if they are controlled by Design Status. Here is the condition.

COND ( ATTRIB OWNER OF VALREF EQ ID /DesignStatus )

A suitable error message would be: "DAC: You may not remove Design Status from this object".

Example Where a User May Only Amend Status

This example illustrates how to prevent a User from making any changes, other than those related directly to status assignment and transition.

Create a PEROP that grants all operations to the status hierarchy. The PEROP should be applied to the following element type:

STLNKW HIERARCHY

This will apply the PEROP to all objects in the status hierarchy. Assign this PEROP (and only this PEROP) to the User.

This is a positive Data Access Control. It grants access rights to objects. It is therefore not possible to define a specific DAC error message which will be shown if the User tries to carry out a forbidden action (for example an attempt to create an element). A generic DAC error message will be shown in these cases.

Example to Prevent Issue of an Object That Does Not Have Sufficient Status

This is to prevent a User from issuing an object that has not been assigned a status or the status has not reached a sufficient level.

Create a PEROP that denies issue operations on equipment when the Design Status is not assigned or is less than 100. Here is the condition:

COND ( UNSET( STVLSK ) OR ATTRIB STVNUM(ID / DesignStatus ) LT 100 )

A suitable error message would be: "DAC: You may not issue this object until it has been Approved".