There are four hook execution points while a record is open:
Before committing changes to the database, or when a validation is requested from a ClearQuest® Web or RCP client, the Rational® ClearQuest software validates the record by running hooks in the following order:
You can modify the access control to actions, including actions that might be added to your schema by applying packages. However, any access control restrictions placed in base actions apply to all other actions. For nested actions, an access control hook is not run.
If a Field Value Changed hook calls the SetFieldValue method of the Entity object, the VALUE_CHANGED hook for that field runs at the time of the SetFieldValue call.
Certain hooks do not run while a nested action is in progress, including the execution of access control hooks and all notification hooks. For more information, see Actions and access control and Hooks in nested actions in the IBM Rational ClearQuest API Reference.
When a user edits a record, the hooks run in the following order:
If the Limit to list option is set and the user enters a value that is not allowed, the field is marked as not valid. The next hook runs only when the user enters a valid value.
If a Field Value Changed hook calls the SetFieldValue method to change the value of another field, the Field Value Changed hook for the other field runs immediately.
If you use dependent fields with the Recalculate Choice list option, the Field Validation hook runs first and then the Field Choice List hook for each field runs, until all changed fields are set and validated.
Field hooks run only when the user starts the Submit action, unless the field is marked as having dependent fields. See Using hooks to detect a Web session.
Before committing changes to the database, Rational ClearQuest software validates the record by running hooks in the following order:
The Commit hook runs after the database is updated with changes to the current record, but before the update transaction has been committed to the database. You cannot use a Commit hook to modify the current record (for example, you cannot make changes to a field from a Commit hook).
Work in a Commit hook is completed while locks exist in the database, and those locks might prevent other users from running queries, creating new records, or modifying existing records. For performance reasons, it is best to minimize the work performed in a Commit hook.
Use a Commit hook only for actions against other records that you want to be part of the same database transaction as the main action (for example, resolving a duplicate defect when the parent defect is resolved). You must ensure that you are placing the appropriate calls in the correct context. For example, you do not call Revert from a Commit hook, nor do you call Commit from any action other than a Commit hook.
After a record is validated, it is committed to the database by hooks that run in the following order:
For more information, see Editing an existing record in the IBM Rational ClearQuest API Reference.