Operation preconditions and follow-up actions

Edit online

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

Table 1 lists and describes the available preconditions.

Table 1. EWM preconditions
Category	Operation	Precondition	Description
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: Only the user who requested the build can abandon it. Only the requestor or a member of the team area that owns the build definition can abandon it.
	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: Only the user who requested the build can cancel it. Only the requestor or a member of the team area that owns the build definition can cancel it.
	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 Build (server)	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.
Git	Push Operation (server)	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.
Promotion	Promote Work Items (server)	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.	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	Deliver operations fail if the work item approvals are not complete.
		Require Work Items and Comments	Deliver operations fail if the change sets do not include comments or associated work items.
	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 associated to a work item have a minimum number of approvals. The approvals are specified by role and must be complete before the associated change sets are delivered to a stream. By default, only work item approvals are considered. If you select the Approvals of type 'Review' must be code review approvals checkbox, only code review approvals are considered for the type 'Review'. 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: Change sets are often delivered by release engineers, so the owner identity check blocks the delivery. If change sets were delivered to the development stream in previous iterations, then associated work items were likely targeted to those iterations.
		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 Streams or Workspaces to be Synchronized Before Delivery	Ensures that you do not have incoming changes at the time of delivery. You can limit the scope of this precondition to specific components. This precondition ensures to allow delivery only when the source stream or workspace is synchronized with the target stream or workspace. It also ensures that you have all the changes in a stream or workspace before you complete a delivery operation and 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 ignored. 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.
		Required Content	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

Table 2 lists and describes the available follow-up actions.

Table 2. EWM follow-up actions
Category	Operation	Follow-up action	Description
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.
Process:	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.