This page specifies the conditions that cause a trigger to fire. This information on this page was specified when the trigger type was created.
If you have the proper permissions, you can modify this information by using the mktrtype -replace command on the command line.
In effect, an instance of the type is implicitly attached to each element in the VOB. This trigger type is useful for disallowing creation of elements that have certain characteristics.
If a post-operation trigger action returns a nonzero exit status, a failed exit status warning message is displayed, but any other trigger actions continue.
This kind of trigger is useful for recording the occurrence of the operation. For example, a post-operation trigger on checkin might attach an attribute to the checked-in version and send a mail message to interested users and/or managers.
This type of trigger is useful for enforcing policies. For example, a pre-operation trigger might prohibit checkin of an element that fails to pass a code-quality test.
If a post-operation trigger action returns a nonzero exit status, a failed exit status warning message is displayed, but other trigger actions, if any, continue.
This kind of trigger is useful for recording the occurrence of the operation. For example, a post-operation trigger on checkin might attach an attribute to the checked-in version and send a mail message to interested users or managers.
In effect, an instance of the trigger is implicitly attached to each UCM object in a PVOB.
By default, triggers fire no matter who performs the specified Rational ClearCase operation.
The items on the restriction list form a logical condition at trigger firing time. If the condition is met, the trigger fires; otherwise, the trigger does not fire.
If the list includes multiple type objects, they are combined into a compound condition according to the following rules:
In forming the condition, a type object is ignored if it could not possibly be affected by the Rational ClearCase operation.