Operation Behavior (preconditions and follow-up actions)

Edit online

Operation behavior defines preconditions and follow-up actions for individual operations. This behavior encourages or enforces process rules for your project and teams. Behavior is defined in the process configuration for the project and can be customized by team areas.

Preconditions and follow-up actions are applied in the context of an operation. For example, for the Work Item Save operation, you can use a precondition to define which fields in a work item must be filled in before it can be saved. If a required field is incomplete, then the save operation is blocked and details are provided in the Team Advisor view and in the title bar of the work item. The following figure provides an example of a precondition that must be met before delivering code to source control.

Figure 1. Precondition alerts are displayed in the Team Advisor view
This picture shows an alert in the Team Advisor view. A deliver operation has failed, and the alert tells the user that the operation failed because they did not associate a work item with the change set.
Note: If multiple preconditions are specified for an operation, all of the preconditions are evaluated, even if one of them fails. This behavior ensures that users are alerted to all unsatisfied preconditions that would cause the operation to fail.

Follow-up actions can make additional changes to artifacts in the repository after an operation is successfully completed, as defined by the process. For example, The Scrum process currently generates three work items in response to the operation of joining a team: Create a Repository Workspace, Find Your Work Items, and Set Up Instant Messaging.

Jazz® process templates include a collection of operations with preconditions and follow-up actions. The predefined operations vary in the different process templates. The following table shows the preconditions and follow-up actions that are enabled by default in the predefined Scrum process template. To disable or modify any of these preconditions or follow-up actions, see Modifying operation behavior (preconditions and follow-up actions) in project areas and team areas.

Table 1. Predefined operations, preconditions, and follow-up actions in the Scrum process template
Operation Precondition/Follow-up action Comments
Generate Team Invitation (server) Create initial work items This follow-up action creates a set of work items for the tasks you need to perform to complete the process of joining the team.
Accept Team Invitation (server) Show work items When you accept the invitation to join the team, a query is run to display your assigned work items.
Work Item Save (server) Required attributes for type and state Team members are advised to complete certain fields in work items before they can be saved.
Source Control Deliver Operation Descriptive change sets Team members are advised to associate a work item with every code delivery.
No unused imports Team members are advised not to deliver any code that contains unused imports.
Clean workspace Do not deliver changes if your workspace contains compilation errors.
In the IBM® Engineering Workflow Management (EWM) client for Eclipse IDE, behavior is defined on the Process Configuration tab of the Project Area editor and the Process Template editor. These settings apply to the entire project. To modify behavior for a team area, use the Process Customization tab or Process Customization Source tab of the Team Area editor. You cannot define operation behavior in the web client. Within the Process Configuration tab of the Project Area editor, you can specify permissions at different levels of the hierarchy, as shown in the following image. See Table 2 for descriptions of the scope of these settings.
This image is a screen capture of the Process Configuration tab of the Project Area editor. It shows the different places in the project area hierarchy where you can configure operation behavior.
Table 2. Operation behavior in the project area hierarchy
Location of operation behavior setting Description
Project Configuration Operation behavior at this level applies to the global project context. The behavior applies regardless of the current iteration or timeline, and it cannot be customized in specific team areas.
Team Configuration Operation behavior at this level applies to all of the teams that belong to the project area. However, each team area can customize the behavior.
Iteration Types Operation behavior at this level applies to all iterations of the iteration type. Each team area can customize the behavior for iteration types.
Timelines Operation behavior at this level applies to all team areas in the timeline.
Iterations Operation behavior at this level applies to all team areas in the iteration's timeline when the iteration is the current iteration.
At run time, the most iteration-specific behavior is used. For example, if your team defines behavior at the top-level, that behavior applies to all iterations. However, if your team then configures behavior for a specific iteration, that behavior is used when that iteration is current. In order from highest priority to lowest, the process run time chooses:
  1. Operation behavior specified for the current iteration or for the iteration type of the current iteration.
  2. Operation behavior specified for the parent of the current iteration or for the iteration type of the parent iteration (all the way to the root of the hierarchy).
  3. Operation behavior specified for the team area timeline.
  4. Operation behavior specified at the top-level of the team configuration of the project area.

Process permissions and operation behavior are configured independently. Your team can choose to customize the permissions, the behavior, or both, for the operation.

You can configure different operation behavior for each role. Unlike permissions, operation behavior is not additive. The process run time chooses the most appropriate operation configuration for the logged-in user and uses only the preconditions and follow-up actions defined in that configuration.
Note: Because all users are assigned the default Everyone role, you can have specific operation behavior apply to all users by specifying it for the Everyone role; you need not specify it for every role. At runtime, EWM checks the operation behavior settings for all other roles assigned to the user before checking the operation behavior for the Everyone role. If operation behavior is specified for one of those roles, EWM uses that operation behavior instead of the operation behavior that is specified for the Everyone role.

For a detailed explanation of how the process component determines which behavior to enforce at run time, see http://jazz.net/library/article/292.

For information about creating custom preconditions, see Extensions Workshop.