You are not logged in. Click here
to log in.
Codebeamer Application Lifecycle Management (ALM)
Tracker WorkflowsTable of Contents
OverviewTeam members can collaboratively resolve their issues using workflows. These issues might be bugs, tasks or requirements. Project administrators can easily setup workflows that allow team members to readily collaborate in the workflow process to manage their issues. For example, a customer or a test engineer can directly enter bugs into a tracker, and developers (one developer, or all belonging to a role) are automatically notified about the bug. A developer can fix the bug, associate the source code changes with the bug, and set the bug status to fixed. The source code change association with the bug is typically performed by associating a commit with the issue. Team members' project roles determine which notifications they receive in this corrective process. Workflows provide better change control for critical tasks or requirements where the change has strong impact on resources or deliverables. CodeBeamer trackers integrate a simple and flexible process engine to model business process workflows. This flow control mechanism can be used to enforce proper business processes in the trackers and to improve business operations. For information on Document Workflows, please see You must login to see this link. Register now, if you have no user account yet..ConceptsIn CodeBeamer, business processes are modeled as finite state machines. This intuitive model is based on two basic concepts from graph theory:
Workflows can be configured differently for each tracker. The graphical representation of the default tracker workflow definition in CodeBeamer is shown in the next figure. Figure: Default Tracker Workflow. You must login to see this link. Register now, if you have no user account yet. The above diagram contains the following node types:
As a sample scenario, when a developer confirms that a bug report is valid, then he is allowed to move it from Unconfirmed state to Verified state. At this point, he can't simply mark it as Reopened, because there is no such transition defined, as that would violate the business process. The state machine's business rules are applied to all users. Working With WorkflowsTrackers workflows are easy to understand. They are almost identical to trackers without workflows. The only real difference in the user interface is that the status selector of a tracker item will not be enabled anymore, but defined transitions can be chosen by clicking on the Transitionslink at the top: Figure: Work Item with Active Workflow.
Only the allowed transitions will be available. Field Edits on TransitionsWhen a transition is selected, a transition's tracker-edit window appears. In this edit window, a particular field is editable if the user has write permissions on the field in either the source or target states, for that transition. After the edits, if any, the user selects either Submit or Submit and New to complete the transition. In the new state, the field will be as edited in the transition's edit window. So, for example, if the field Summary is editable in the states Resolved and Reopened, but Summary is not editable in the Closed state, then the Summaryfield will be
Workflow Transition PermissionsOnly a user with proper permissions is allowed to move an item to a new state. Transition permissions can be set up in the Transitions tab in the Tracker -> Customize screen by checking what conditions are required to take certain transitions. Note that there is a logical OR relation applied to the permissions of the Account and Role groups. It is enough to have only one of the conditions applicable to a user for him to be allowed to make the transition. Customizing WorkflowsThe workflow can be activated or deactivated on a tracker basis in the General tab of the Tracker -> Customize screen. The workflow on each tracker can be enabled or disabled at any time. To enable a tracker workflow:
Figure: Enable a Tracker Workflow.
Disabling the workflow will make every user able to move a tracker item from any status to any other status. CodeBeamer supports custom workflows by allowing user-defined statuses and transitions. With this, users have the flexibility to configure the workflow to match their desired processes. A typical use case for a custom workflow is to model your company standard bug approval process. It is advised to design the workflow definition with some graph designer tool or even on paper first, and then input the design:
To customize the workflow transitions:
Figure: Customize Workflow Transitions Invalid link [!state-transition-settings.png!] Field values can be overwritten with override values during transitions,using the More -> Customize, State Transitions tab, and Edit for the particular, selected transition. Figure: Field Value Override Definition in Workflow Transition Edit Invalid link [!edit-transition.png!] Tracker fields can acquire default values, which are inserted when there is no field value imported into the state along a transition. Update the default values for a state using the Fields tab in Tracker-> Customize. Figure: Customize Field Permissions Invalid link [!status-permission.png!] Status and Resolution MeaningCustom states and resolutions in CodeBeamer have always been user-definable, but an unanswered question was: "What does it mean ?" To provide more flexible default filters and views, you can now associate meaning (intent/behavior) with your custom states and resolutions. Figure: Custom Meaning for Resolution Invalid link [!resolution-option.png!] Figure: Custom Meaning for Status Invalid link [!status-option.png!] Status meanings:
Resolution meaning:
With these new definitions, the filter/view "Closed" now includes all issues whose status means Closed, and "Open" excludes all issues whose status means Closed. Same for "Resolved"/"Unresolved" and "Successful"/"Unsuccessful". "Obsolete" (formerly "Deleted") is an attribute of the (status/resolution) choice option and indicates an obsolete choice option, that should not be used any more. It doesn't mean that issues with this status/resolution are deleted. Prior to CB-5.5 there always had to be a status with ID 6, which implicitly meant "Closed". This constraint is gone, and you are now absolutely free in your status definitions. There can even be multiple or no "Closed" or "Resolved" states.Status Specific Field Value FiltersWhen workflow is enabled in a tracker you can now define filters to allow only certain values in the status field. This is especially useful for member fields, e.g. "Assigned To" or "Supervisors", because you can now explicitly define responsibilities for specific states of issue processing, even enforce a re-allocation of responsibility (e.g. "Two-man rule") upon a status change. Example: A simple bug handling process Figure: A Simple Bug-Handling Process You must login to see this link. Register now, if you have no user account yet. Responsibilities in CodeBeamer are defined via project roles, e.g.: Figure: CodeBeamer Project Roles
For simplicity, only the core workflow is shown. In real life you will need more states and transitions, e.g. to reject fixes which didn't pass quality tests, etc. You can now assign a specific workflow/process status to a role, via the column "Allowed Values Filter" in Tracker -> Customize -> Fields. Example: Status "New": Figure: Status Role-Specific Workflow via "Allowed/Default Values" Invalid link [!priority-allowed-values.png!] For sensible quality assurance, we also want to make sure that this fix or feature is tested by someone who was not involved in fixing the bug, so we check the "Two-man rule" option (see below). Two-Man RuleIf you assign a status to different role than the previous status' assigned role, it does not necessarily enforce a change of responsibility. Project members can be assigned to multiple roles at the same time, and assigning a task to a user who is in both roles would satisfy both responsibility constraints. So, for example, the person responsible for fixing a bug could also be in a role (and that role assigned to one of the subsequent tracker workflow states) that allows him/her to approve the fix. With the "Two-man rule" option
Figure: Transitions' Permissions Invalid link [!state-transition-settings.png!] status' field has the "Two-man rule" option set, we strongly recommend clearing the old field value in all transitions (in)to that status, so that the user is forced to enter a new field value during that transition. Example: Clear value of "Assigned To" upon transition from "Verified" to "Fixed".Figure: Clear Field Value During Transition To Force New Field Value Entry Invalid link [!new-transition.png!] Transition ActionSince CB-5.5, CodeBeamer also provides a new framework to extend workflow transitions with custom actions. To implement a custom workflow action, write a Java class and make it extend DefaultWorkflowListener and override beforeTransition(), afterTransition() or both. See ScmChangeFileZipper.java for a working example: package com.intland.codebeamer.event.impl;
import org.apache.log4j.Logger;
import com.intland.codebeamer.event.BaseEvent;
import com.intland.codebeamer.manager.util.ActionData;
import com.intland.codebeamer.persistence.dto.TrackerItemDto;
import com.intland.codebeamer.persistence.dto.WorkflowTransitionDto;
/**
* A special WorkflowListener, to listen for specified workflow transitions and pack all source files associated
* with the subject tracker item into a ZIP archive and attach that archive to the tracker item.
*/
public class ScmChangeFileZipper extends DefaultWorkflowListener {
private static final Logger log = Logger.getLogger(ScmChangeFileZipper.class);
@Override
protected Logger getLogger() {
return log;
}
/**
* Create a ZIP file of all modified sources associated with the subject and attach to the subject
* @param transition this action was associated with
* @param subject is the issue the action was called upon
*/
@Override
protected void afterTransition(BaseEvent<WorkflowTransitionDto,TrackerItemDto,ActionData> event, WorkflowTransitionDto transition, TrackerItemDto subject) {
super.afterTransition(event, transition, subject);
try {
...
} catch (Throwable ex) {
getLogger().error("afterTransition(" + transition + ", " + subject + ") failed", ex);
}
}
}
For CodeBeamer, to recognize your custom workflow action, compile it and put the compiled class file in the CodeBeamer class path, e.g. ~CB/tomcat/webapps/cb/WEB-INF/classes. Next, you must register your custom Workflow Listener: For CB-5.6 and older:Edit ~CB/tomcat/webapps/cb/WEB-INF/classes/general.xml and add an entry for your custom workflow action class to the <listeners> section, e.g. <listeners> … <listener id="scmChangeFileZipper" class="com.intland.codebeamer.event.impl.ScmChangeFileZipper" > <init-param> <param-name>label</param-name> <param-value>Attach ZIP of changed sources to tracker item</param-value> </init-param> <init-param> <param-name>iconUrl</param-name> <param-value>/images/cvs_view.gif</param-value> </init-param> </listener> </listeners> For CB-5.7 and newer,you must deploy and register you custom listener according to You must login to see this link. Register now, if you have no user account yet. via an my-applicationContext.xml file, e.g. ...
<bean id="scmChangeFileZipper" class="com.intland.codebeamer.event.impl.ScmChangeFileZipper" >
<property name="id" value="scmChangeFileZipper"></property>
<property name="label" value="Attach ZIP of changed sources to the issue"></property>
<property name="iconUrl" value="/images/cvs_view.gif"></property>
</bean>
<bean id="myListenerListFactory" parent="listenerListFactory">
<property name="sourceList">
<list merge="true">
<ref bean="scmChangeFileZipper"></ref>
</list>
</property>
</bean>
<bean id="eventMulticaster" class="com.intland.codebeamer.event.EventMulticaster" factory-method="getInstance" lazy-init="false" >
<property name="listeners">
<ref bean="myListenerListFactory"></ref>
</property>
</bean>
Finally, restart CodeBeamer. To associate your custom workflow action with a workflow transition: Edit the transition, choose your action from the Action dropdown list and save. Figure: Associate Workflow Action with Workflow Transition Invalid link [!state-transition-settings.png!] Transition GuardSince CB-6.0, CodeBeamer also supports guards per transition. A guard is a filter/condition (in form of a public tracker view), that will be checked upon transition execution and must yield true in order for the transition to proceed. For example: The "No unresolved issues" guard for the "Release" Version transition: Invalid link [!add-guard.png!] The "No unresolved issues" guard itself is a public tracker view (on "Versions") that makes use of the new "References" filtering: Invalid link [!edit-guard.png!] In the above example, "No unresolved issues" only yields true if no unresolved issues (of any type) refer to the current Version as "Target Version". Cross Tracker WorkflowWatch a video on the cross-tracker workflow here.
Also since CB-6.0, Codebeamer supports workflows accross multiple trackers (involving related issues of different types). feature has been completely refactored in CB-6.1.All cross tracker workflow settings configured in CB-6.0.x will get lost upon upgrade to CB-6.1 This cross tracker workflow only works with dependencies defined via tracker reference fields (not associations). For each outgoing reference to other entities (via reference fields) and also for each incoming references (via reference fields of other trackers refering to the current tracker), the Field values of referenced/referring issues to update upon transition section of a Create/Edit workflow transition dialog, allows to define triggers, that also updates fields or invoke workflow transitions of referenced/referencing items/issues. Invalid link [!add-transition-testcase.png!] In the above example we show a "Test Case" transition. For a better understanding of the shown references, we need to look at the Tracker Class Diagram (also available since CB-6.0): You must login to see this link. Register now, if you have no user account yet. You can see that
|
codebeamer Overview codebeamer Knowledge Base Services by Intland Software |
anonymous
Hotkeys