Rules and Attributes

Rules and attributes deal with defining rules for the instances of an object. The rule triggers the events for the set of entities that have been retrieved from the rule. Each of the events that are triggered can, in turn, trigger other dependent events.

This concept was developed to provide the user with a one-point provision to trigger dependent events.

Basic concepts of rules and attributes

Some of the basic concepts of rules and attributes are as follows:

Object Data Management facilitates the creation of data in terms of objects and the object’ s relation to the other objects.

Some of the entities, such as document revisions, change requests, folders, and so on, undergo a lifecycle change.

During the life-cycle change, you cannot trigger the lifecycle change of other dependent entities.

You can use rules as one-point provisions to trigger these types of dependent events.

Example

If a folder is undergoing a lifecycle, change from In-design to Approved. If documents were linked to the folder, which are in In-design status, enabling the user to change the status of the linked documents from In Design to Approved would be useful. Therefore, these documents are also in line with the status of the folder. In these types of scenarios, you can use rules, which, on definition, not only trigger the lifecycle of the calling object, but also the lifecycle events of other dependent entities that are retrieved by the processing of the rule.

Note

Attributes and queries contribute to classifying of objects that must be retrieved by a rule.

Attribute usage to define a rule
Example

The rule is to submit only the specified documents created by a role called Manager. In addition, the documents attached as child documents must also be submitted to a predefined vault area.

Create the documents Doc-1, Doc-2, and Doc-3. The role defined in the documents is Manager. Attach the child document revisions to the revisions of these defined documents. The condition cannot be specified for this rule, because the user wants to submit only Doc-1 and Doc-2. Therefore, the instance of the owner must be defined in an attribute. If multiple instances exist for Owner, you must define these attributes in multiple attributes. Define the instance of Doc-1 and Doc-2 in the attributes. Whenever Doc-1 or Doc-2 is submitted, the child document revisions attached to the document are submitted to the vault area to check the rule associated with these documents.

This case demonstrates the condition that exists for source event only in a rule. The target object and target event do not exist.

The rule defined is to submit all the documents created on a specific date. To realize this, you must define a query, which retrieves documents created on a specific date. Specify the source object as Docs and the source event as Submit .

Define a query for which the query condition is Documents created on 04.08.2002 . All the documents created on the specified date will be retrieved. Now, the rule is executed and submits all the retrieved documents by query.

Authorizations for rules and attributes

The standard ODM authorization mechanism is used to determine the actions to be performed by individual users on various rules and attributes entities.

ActionObjectDescriptionOutcome
CREATE_RULERULECreate a business ruleCreate a rule, based on query condition or attribute.
DELETE_LOGRULEDelete a log for a business rule
DELETE_RULERULEDelete a business rule
EXECUTE_RULERULEExecute a rule
GLOB-RULERULEAction group for rule
MODIFY_RULERULEModify a business rule

 

The system administrator assigns roles to LN users in the Roles by Employee session. User roles are assigned permissions to perform different operations on different objects, using the ODM authorization mechanism. Conditions can be associated with permissions to specify that a user role can only perform a specific action on an object if a particular condition is fulfilled.

[...]