Workflow Rules Settings
The Settings tab of the example_rules.xlsx file contains several settings for the rules engine.
| Setting | Description |
|---|---|
| SUPER_USER_NAME | The user name of the
ProjectWise account to be used for actions
marked on the Rules tab as requiring a
"super user" (Super User=TRUE). This is a user
with elevated rights over normal users to allow actions to be carried out if
the user running the operation does not have permission to do so. For example,
with the Super User setting an attribute may be set, even though the user does
not have write access to the document in the current state. When such an action
occurs, Audit Trail will show the Super User as the user who carried out the
action.
The user name specified here will be validated when the rules are imported. If the user name does not exist, the rules import will fail. |
| SUPER_USER_PASSWORD | The password for the Super User account. This will be validated on import. If the password is incorrect for the specified user name, the rules import will fail. |
| ROLLBACK_USER_NAME | The user name of the
ProjectWise account to be used for rolling
back failed operations.
The user name specified here will be validated when the rules are imported. If the user name does not exist, the rules import will fail. |
| ROLLBACK_USER_ENC_PASSWORD | The password for the Rollback User account. This will be validated on import. If the password is incorrect for the specified user name, the rules import will fail. |
| BNT_REV_NO_ATTR_NAME | The attribute name of the main
revision attribute that will be synchronized with the standard
ProjectWise
Version property on the General tab of the
Document Properties dialog.
If set, when a document is saved, the value of this attribute will be saved into the Version property. This also means that if the user manually edits the Version property, it will be overwritten with the value of the attribute the next time the document is saved. |
| BNT_REVSION_ATTRIBUTES | These are the attributes that
are affected by the
SHIFT_REV_HISTORY action. In the example
interface below, there are 12 rows of attributes, with the active row at the
bottom. Each time the
SHIFT_REV_HISTORY action is called, the rows are
all shifted up the interface, row 1 to row 2, row 2 to row 3, etc.
In order to do this each attribute is defined for the number of rows required. For example, looking at Column 1, the Revision column, the bottom row has an attribute named RV_REV_1, and the second row has attribute RV_REV_2, and so on up the screen until the top left is named RV_REV_12. These are defined in the setting table by RV_REV_ without the number. The number is defined in the next setting. Each column follows the same pattern. So the date column will be named RV_DATE_1 to RV_DATE_12, and will be defined in the settings as RV_DATE_. Each value is separated by a semi-colon (;). For the seven attributes shown in this example, these are defined in the settings as: RV_REV_; RV_DATE_; RV_NOTE_; RV_BY_, etc. |
| BNT_REVISION_HISTORY_COUNT | The number of revision history rows defined. |
