The first entry in the table of validations is special. Its condition is always "initialization of new issue", so that its actions are performed exactly once: between the time the user invokes the New Issue command and the time the new Issue form appears.
To define an action, right-click in the Actions column, then select Add Action from the context menu. An Action window appears, in which you define the action. For initialization of a new issue record, the only appropriate action type is setValue. (Note: Some releases of AccuWork allow you to include setRequired and setChoices actions in a record initialization. Such actions will be ignored when a new record is initialized.)
After setting the action type to setValue, select a field to be initialized and specify the initial value. The Value edit-widget adjusts to the selected field. In the example below, the data type of the state field is choose, so the list-box offers the field's predefined choices as the initial value.
The setting of initial field values is an unconditional validation: it happens every time a New Issue command is invoked. All other validations are conditional: a certain set of actions are performed if, and only if, a certain condition is met.
The unconditional setting of initial field values occurs just once; but the conditional validations are performed repeatedly: when an Issue form first appears and each time the user changes any field value. Each repetition involves:
To create a new conditional validation -- that is, a new row in the table -- right-click anywhere in the Conditions column, then select Add Condition from the context menu. Then proceed to construct the "if" clause. The same context menu provides the Edit Condition command (for revising an existing "if" clause), and the Remove Condition command (for removing a conditional validation).
Specifying the "if clause" of a conditional validation is very much like specifying an AccuWork database query (see Working in the Query Editor). But there are some differences. In a validation condition, you can:
Each conditional validation can include any number of actions. You create an action by right-clicking in the Actions column of the validation, and selecting Add Action from the context menu. This displays a window in which you define the action.
|
•
|
Setting a field value (setValue)
|
|
•
|
Revising the choices for a "choose" field (setChoices)
|
|
•
|
Requiring a value to be entered in a field (setRequired)
|
|
•
|
Setting permissions on all or part of the issue record (setIssuePermission, setTabPermission, setFieldPermission)
|
|
•
|
Requiring change set entries (setChangesRequired)
|
|
•
|
Requiring a relationship with another issue record (setParentRelationshipRequired, setChildRelationshipRequired)
|
|
•
|
Constraining groups displayed (setGroupChoices)
|
|
•
|
|
•
|
In addition to initializing field values (see Initializing Field Values in a New Issue Record), you can set the values of fields while the user is working with the record, based on certain conditions. For example, if the user enters ColorStar in the program_name field, a validation could automatically set the fix_priority field to high . (Management has mandated rapid improvement in the robustness of the ColorStar application.)
To define a setValue action for a validation condition:
|
1.
|
In the Action window, select setValue as the action type, and select the field to be set.
|
|
2.
|
The Value edit-widget adjusts to the selected field, just as it does when you're initializing a field in a new issue record.
|
In a validation, a setChoices action can change the "choice list" that the user will see when he opens the list-box: The changes to the choice list can include:
You cannot add new strings to the choice list with a setChoices action. The changes made by a setChoices action are temporary: they last only until the next setChoices action on the same field, or until the user closes the Issue form. When an Issue form is opened on another issue record (or subsequently on this issue record), the user will see the field's original choice list, as defined on the Schema tab.
To define a setChoices action for a validation condition:
|
1.
|
In the Action window, select setChoices as the action type, and use the Field list-box to select one of the database's fields of type "choose".
|
|
2.
|
Use the controls at the bottom of the Action window to define the temporary change to the choice list:
|
AccuWork affords you great flexibility in controlling required fields. A field's "required" status is not part of the basic database schema. Instead, it is controlled by the conditional-validation facility. Thus, AccuWork repeatedly redecides whether a field is required: when the Issue form first appears and each time the user changes any field value on the Issue form. Whenever the user clicks the Save button, AccuWork uses the current set of required fields to allow or disallow the "save" operation.
To define a setRequired action for a validation condition:
|
1.
|
In the Action window, select setRequired as the action type.
|
If you want a field to be required in all circumstances, use the setRequired action along with a condition that's always true. For example, you can exploit the fact that every issue record has a positive integer as its issue number:
The setIssuePermission, setTabPermission, and setFieldPermission actions are essentially similar: they restrict the editability of some component of the issue record:
|
•
|
setIssuePermission makes the entire issue record read-only.
|
|
•
|
setTabPermission makes a particular page (tab) of the Issue form read-only.
|
|
•
|
setFieldPermission makes a particular field of the issue record read-only.
|
|
•
|
ro— Make read-only for all situations.
|
|
•
|
auto— (AccuRev Workflow only.) Make read-only for end-users, but allow AccuRev to make changes.
|
The "read-only" ( ro ) permission affects the user's current access to the issue record; the "read-only" status is not stored in the repository as part of any issue record. For example, user allison might find that she cannot change any fields on the Assignment page of any issue record, because of this validation:
This restriction affect allison 's access to issue records; other users' access remains unaffected. And if this conditional validation is subsequently removed, allison will regain access to the Assignment page of all the issue records.
Note that setting read-only permission on an issue record will affect the behavior of AccuRev commands such as cpkremove and promote, in addition to restricting the user's ability to edit the issue.
The “automatic” ( auto ) permission is similar to ro, but in AccuRev Workflow, AccuRev can perform actions that end-users are prevented from making as described above. For more information about AccuRev Workflow-specific details, see the AccuRev Web Interface User’s Guide.
The setChangesRequired action specifies that the user cannot Save an issue record unless there is at least one entry in the issue record's change package.
Note: Be careful not to specify this action with the "initialization of new issue" condition (see Initializing Field Values in a New Issue Record).
The setParentRelationshipRequired action specifies that the user cannot Save an issue record unless there is at least one entry in the lower table of a particular relationship field.
The setChildRelationshipRequired action specifies that the user cannot Save an issue record unless there is at least one entry in the upper table of a particular relationship field.
You cannot set both these requirements for the same relationship field, because each field can have parent relationships or child relationships, but not both.
Each conditional validation consists of a condition (left column) and a set of actions (right column). To revise or remove an entire validation, right-click anywhere within the condition, and select the appropriate command, Edit Condition or Remove Condition, from the context menu.
To revise or remove an individual action from a validation, right-click on that action and select the appropriate command -- Edit Action, Remove Action, or Add Action -- from the context menu.
Tip: You might want to use the "initialization of cloned issue" actions to reset field values for an issue record when it is cloned. For example, rather than using the original issue record’s dateSubmitted value for the cloned issue (AccuWork uses all of the original issue’s values by default), you might want to use a setValue action to change dateSubmitted to "CUR_DATE". See Cloning an Issue for more information on this topic.