Operation preconditions and follow-up actions
You can modify the behavior for operations in a project area or team area by defining preconditions and follow-up actions that are required for individual operations. Preconditions are conditions that must be met before an operation can be completed. Follow-up actions are events that are generated, like work items that are created, when the operation is completed.
IBM® Engineering Workflow Management (EWM) preconditions
|Build||Abandon Build (server)||Restrict the Users Abandoning a Build||
Restricts the users that can abandon a build. You can configure this precondition as follows:
|Cancel Pending Build Request (server)||Restrict the Users Canceling a Pending Build||
Restricts the users that can cancel a pending build. You can configure this precondition as follows:
|Restrict Build (server)||Restrict the Maximum Number of In-progress and Pending Builds||Restricts the in-progress and pending builds to a maximum number allowed.|
|Restrict the Users Requesting A Build||Restricts the users that can request a build. Only users who are members of the team area that owns the build definition can request a build.|
|Git||Push Operation (server)||Push Own Commits||Allows only push of commits created by the user.|
|Require Work Item hint in Commit Comment||Allows only push of commits that have work item hint in its comment.|
|Packaging||Request Package (server)||Require Work Item States||Verifies that a work item can be packaged only if it is in one of the configured states.|
|Promotion||Promote Work Items (server)||Check build maps for source only promotion||Require the promotion to check build maps for source only promotion.|
|Require Work Item States||Verifies that a work item can only be promoted if it is in one of the configured states.|
|Source Control||Check-in||Restrict Change Set Size||Restrict the number of changes that can be contained within a single change set.|
|Restrict Check-in Based on Specified MIME Types and Encodings||Restrict Check-in of files based on the specified MIME types and encodings.|
|Restrict Check-in of Resources With the Same Name||A resource cannot be checked in when its name is the same as another resource in the same location, even when the capitalization is different.|
|Restrict File Size||Files cannot be checked in when they exceed the specified size limit.|
Deliver (client). The precondition runs before delivery of baselines, change sets, or on a component replacement. Affects all components in streams that are owned by the process area.
The Deliver (client) precondition runs on the client before the server is contacted about the delivery. This operation is appropriate for preconditions that require client state to run, such as detecting compilation errors, or whether the most recent JUnits completed.
|No Unused Imports||Deliver operations fail if the change sets include unused imports.|
|Clean Workspace||Deliver operations fail if the change sets include compilation errors.|
|Descriptive Change Sets||Deliver operations fail if the change sets do not include comments or associated work items.|
|Prevent Unintended Ignored Changes||Deliver operations fail if you set a file to be ignored after another user sets the same file to be ignored (z/OS only).|
|Prohibit Non-Externalized Java Strings||Deliver operations fail on Java files that have non-internationalized strings.|
|Prohibit Unused Java Imports||Deliver operations fail on Java files that have unused imports.|
|Prohibit Workspace Errors||Deliver operations fail if there are compilation errors in the files in the Eclipse workspace or open Visual Studio solution.|
|Require JUnit Test Run||Requires a JUnit test to run (successfully) in the Eclipse workspace.|
|Require Static Analysis run (Microsoft Visual Studio Client)||Require a static analysis tool to run on Visual Studio projects before a deliver operation.|
|Require Unit Test Run (Microsoft Visual Studio Client)||Require either MSTest or NUnit tests to be run on projects before a deliver operation.|
|Require Work Item Approval||Change sets that require approvals can be delivered.|
|Require Work Items and Comments||Change sets that have work items and comments can be delivered.|
Deliver (server). The precondition runs before delivery of baselines, change sets, or on a component replacement. Affects all components in streams that are owned by the process area.
The Deliver (server) operation runs on the server before change sets are added or removed from a component. The operation is run on the set of change sets that are being added to (or removed from) a component.
|Require Work Item Approval||
Verifies that change sets that are linked to a work item have a minimum number of approvals. The approvals are specified by role and must be complete at the time of delivery.
The precondition ensures that a minimum number of approvals are received before the associated change sets can be delivered to a stream.
Note: To prevent users from linking new change sets to work items that already have approvals, enable the Prevent Linking to Approved Work Items precondition.
|Require Work Items and Comments||
Verifies that change sets have work item links and/or comments. The precondition can be configured to require change sets to have a comment/OSLC link, or a work item.
If a work item is required, the owner and target iteration can be verified. Although it makes sense to constrain the work item owner and iteration in development streams, this requirement is not true of integration streams, since:
|Require Work Items to Match Query||
When delivering change sets, ensures that associated work items match a query.
This precondition verifies that the work items associated with each change set are listed in a work item query result. The precondition applies to all streams that are owned by the project/team area for which that precondition is set.
The query allows complex validation of a work item's fields, including custom attributes. Options on the precondition allow the process author to set whether each change set must have at least one matching work item or whether every work item must match.
Work item queries can match only work items in their process area. The precondition allows the process author to control how work items from other process areas are handled: either allowed or denied.
|Require Workspaces to Be Caught Up Before Delivery||
Ensures that you do not have incoming changes at the time of delivery. Since users might be responsible for only some of the components in a stream, the precondition can be limited to check specific components.
This precondition ensures that you have all of the changes in a stream before completing a delivery operation, so that you can test with the full stream content. This scenario works well in IDEs where source is built automatically after an accept operation.
|Restrict Change Set Delivery to Components in a Stream||
Limits the roles that are allowed to deliver change sets to components in a specific stream. This restriction prevents teams that do not own a component from delivering changes to it. You can specify which repository workspaces or streams can deliver changes to a component.
When multiple teams are flowing into a single integration stream, it is useful to limit delivery privileges to the team that owns each component, rather than allow any developer to deliver to any component.
Note: Unlike other preconditions, this precondition operates on all roles, so only assign it to the Everyone role.
|Restrict delivery to streams||Use this precondition to specify whether changes are delivered to the stream
when the changes are not part of a promotion. When you run a promotion, this precondition is
Important: This precondition can only be configured using the EWM Eclipse client. It cannot be configured in the web client.
|Delivery Phase 2 (server). The precondition runs before the delivery of baselines and change sets or on a component replacement. Affects all components in streams that are owned by the process area.||Check Ignore Changes permissions||Changes that are marked to be ignored by a dependency build must have permission to do so.|
Ensures that files contain a specific string on delivery. Only files with names that are matching a specific pattern are checked.
On teams where ownership must be asserted within source code, this precondition allows process authors to force every source file to contain a copyright string.
|Restrict Changes by Item Name||
Prevents changes to files, folders, or symbolic links that are based on their name. The precondition can be scoped to specific components in a stream.
Items can be matched with operators (* indicating zero or more characters, or ? indicating exactly one character) or Java regular expressions. Depending on the precondition's configuration, matching items are either allowed (all items in a change set must match the pattern) or blocked (no items in a change set can match the pattern).
Regular expressions are matched in the manner of a search: the regex matches a substring of the item name. To require the entire name to match, use a caret (^) and dollar sign ($) to anchor the regex to the start and end of the string.
Note: Changes to folders and symbolic links are not considered hierarchically, so preventing a change to all items named src does not prevent delivery of a change set modifying a file in the src folder.
|Restrict Changes to Items||
Limit the roles that are permitted to change specific files. The precondition can either operate in a mode where the changes to the selected files are allowed or denied.
Restricting changes to files allows teams that operate under a lock-down mode to prevent changes to portions of their streams at specific times. Process authors can use this precondition to keep plug-in dependencies stable by matching MANIFEST.MF files or limiting string changes after a string freeze.
|Modify Component (server)||Ensure Component Names are Unique||Prevents component name collisions within a process area. This precondition ensures that no two components in a process area have the same name.|
|Save Change Set Links and Comments (server)||Prevent Linking to Approved Work Items||
Ensures that change sets cannot be linked to work items that already have approvals. This requirement prevents users from using an approved work item to deliver more change sets.
Teams that want to enforce strict process on work items (using Require Work Item Approval, for example) can use this precondition to ensure that all change sets are individually approved before flowing into a stream.
By default, the precondition blocks linking to any work item with approvals, regardless of the approval state. To allow change sets to be linked to work items in specific approval states, add them through the Allowed Link States configuration.
|Prevent Links by Approvers||
Ensures that change set authors do not approve their own work items.
This precondition prevents a change set from being linked to a work item with an approver who is also the change set author. The Require Disinterested Approvers preconditions on work item save prevents an approver from being added to a work item already linked to change sets with the same author. Use these two preconditions together.
|Restrict Associating to Active Change Sets||
Stops incomplete change sets from being associated with work items.
This precondition is useful in processes that require approvals because active change sets can be modified after the approval is granted.
|Restrict Associating to Closed Work Items||
Prevents change set links from being added to or removed from closed work items.
Teams with a strict work item lifecycle can use this precondition to stop change sets from being associated or dissociated with a work item whose work is complete.
You can also use this precondition to add a comment to a work item when links are added/removed and to ensure that the project area of a stream contains the user who is delivering the changes.
|Save Stream (server)||Prevent Adding Component to Stream When Component and Stream Owners are Different.||Prevents adding a component to a stream when component and stream owners are different.|
|Prevent Adding User Owned Component||Prevents adding user-owned components.|
|Restrict Stream Visibility to be set to Public||Prevents setting the stream visibility to Public.|
|Work Items||Save Work Item (server)||All Children Resolved||Requires that a work item can be resolved only if all its children are resolved.|
|Attribute Validation||Verifies that a work item can be saved only if all attribute values are valid.|
|E-Signature||Verifies that a work item can be saved only if an e-signature is given for the configured attributes. For compliance purposes, your organization might require users to provide electronic signatures at specific points during the workflow of a work item.|
|Implied Attributes||Specific attribute changes can trigger changes (setting and clearing) of dependent attributes.|
|Prevent Editing||Prevents a work item from being edited in certain states.|
|Read-Only Attributes for Condition||Verifies that a work item that matches a condition can be saved only if the selected attributes are unchanged.|
|Read-Only Attributes for Type and State||Verifies that a work item that matches the selected types or states can be saved only if the selected attributes are unchanged.|
|Require Disinterested Approvers||Reviewers must not have created any of the change sets that are affiliated with the work item under review.|
|Required Approvals||Verifies that a work item can be saved only if all required approvals are in the configured state. When a user tries to save a work item that requires an approval and the work item is not approved, the save operation fails.|
|Required Attributes for Condition||Verifies that a work item that matches a condition can be saved only if the selected attributes are different from the default value.|
|Required Attributes for Type and State||Verifies that a work item that matches the selected types or states can be saved only if the selected attributes are different from the default value or the null value (for enumerations).|
|Required Constraint Date||Verifies that a constraint date is present when a specific constraint type is selected. The constraint type can be either As soon as possible, Start no earlier than, or Finish not later than. The date is used when either Start no earlier than or Finish not later than is selected. The precondition ensures that when Start no earlier than or Finish not later than are selected, a constraint date is also present.|
|Required Estimates||Verifies that before a work item is marked complete, the work item contains
all the estimates that explain how long the work item took to complete.
Note: This precondition is enforced only when the work item is in one of the closed states such as Resolved or Verified.
|Strict Group Resolution||Requires all children to be resolved before the parent can be resolved, and requires the parent to be open before a child can be added or reopened.|
|Time tracking Owner Check||This configuration enables only the owner of the work item to enter time tracking data.|
EWM follow-up actions
|Packaging||Request Package (server)||Add Work Item Comment||Adds a comment to the work items after packaging completes. The user that performs the operation must have permission to save the work items.|
|Add Work Item Tags||Adds tags to the work items after packaging completes. The user that performs the operation must have permission to save the work items.|
|Modify Work Item State||Modifies the state of the work items after packaging completes. The user that performs the operation must have permission to save the work items.|
|Process:||Accept Team Invitation (client)||Show Work Items||Shows initial work items that are created when user accepts team invitation.|
|Generate Team Invitation (server)||Create Initial Work Items||Creates an initial set of work items for the user who is invited to the team.|
|Promotion||Promote Work Items (server)||Add Work Item Comment||Adds a comment to the work items after promotion completes. The user that performs the operation must have permission to save the work items.|
|Add Work Item Tags||Adds tags to the work items after promotion completes. The user that performs the operation must have permission to save the work items.|
|Modify Work Item State||Modifies the state of the work items after promotion completes. The user that performs the operation must have permission to save the work items.|
|Run Target Build||Runs a target build after promotion completes. The user that performs the operation must have permission to request the target build.|
|Source Control||Save Change Set Links and Comments (server)||Work Item Audit Trail for Change Set Links||Adds a comment to the work item after a change set link is added or removed.|