You are not logged in. Click here to log in.

codebeamer Application Lifecycle Management (ALM)

Search In Project

Search inClear

Tags:  not added yet


This wiki page is for versions before 20.11-LTS (Carmen)
For versions 20.11-LTS (Carmen) and up: Start a new review

If the Start a new review workflow action is not shown on your codeBeamer instance, then please check your system configuration.

  • In CB-9.3 or older: file general.xml:
       <review hideTrackerItemReview="false"/>
     
  • In CB-9.4 or newer: System Admin → Application Configuration:
      "review" : {
         "hideTrackerItemReview" : false
       }
     



Tracker Item Review

Starting with CB-8.0, CodeBeamer provides a new standard mechanism for

  • Reviews and
  • Approvals

of (work) items in specific states, without the need for an extra Approvals tracker and forking extra Approval tasks, as shown in Forking sub-processes from processes (work items).


This new workflow-based review mechanism (in contrast to the still existing old ad-hoc item rating mechanism) gives control over

  • The specific (work) item states, where reviews should be performed
  • The Reviewers (set of users, that are exclusively allowed/qualified to review/approve the (work) item in that specific state)
  • The Reviewconfiguration:
    • What type of electronic Signature(extra reviewer authentication), is required for submitting votes ?
      • None (the user login is sufficient)
      • Password (the user must enter her/his password)
      • Username and Password (the user must enter her/his username and password)
    • In which function/role, did a reviewer perform the review (optional, only in CB-10.0 and newer)
    • How many approvals (positive votes) are necessary, for the subject item to be considered successfully reviewed/approved ?
      • What should be the designated status of approved (work) items ?
    • How many rejections (negative votes) are allowed, before the subject item should be considered rejected/declined ?
      • What should be the designated status of rejected (work) items ?


Review Configuration

To define a review state/stage, simply add the workflow action Start a new review to the appropriate state (entry) or those incoming state transitions, that should trigger the review.

For example: Configure an Approval for the status Waiting for approval of a (System/Customer) Requirements tracker:

Because the approval process should start upon entering the Waiting for approval state, no matter via which transition, we define it as a state entry action.
You can either click on the state in the State Transition Diagram and add the action to be invoked On Entry:





Or you add a new State Entry for the state via the More... selector:










In the example, we choose the Reviewers to be all users, referenced in the field Owner of the requirement to approve:




Also make sure, to grant edit permission for the field Owner. E.g.:




For the Review, we configure, that

  • Submitting votes requires a digital Signature of the reviewers, by entering their Password.
  • That the reviewers should also be ask to specify, in which Role they performed their review (only CB-10.0 and newer).
  • It requires allvotes, for the item to be considered approved, and
    • The designated target status for approved items should be: Accepted.
  • If more than 1 reviewer rejects the item, then the item should be considered rejected, and
    • The designated target status in this case should be: Draft.


Please note, that the placeholder all stands for all actually assigned Reviewers, including the allowed number of Rejects.
So if there are 3 reviewers and the number of allowed rejects is 1, then it actually requires 2 (positive) votes, for the item to be approved.

In general:

  • The number of allowed Rejects must be less than the number of Reviewers.
  • The number of required Approvalsis the smaller/least of
    • The specified number of votes
    • The number of Reviewers minus the number of allowed Rejects (this is what all stands for)


A review started via Start a new review, will automatically prevent editing the subject item, as long as the review is in progress!

State transitions out of a review state, can be associate with the current Review (result), via one of the special Conditions:

  • Subject approved
  • Subject rejected

to only allow this transition, if the review for the current item status was affirmative/positive or declined/negative.

Please note:

  • The state transition to the designated Approved status (if any), is implicitly only applicable, after the subject was approved.
  • The state transition to the designated Rejected status (if any), is implicitly only applicable, after the subject was rejected.

So it is neither necessary nor recommended to set these Conditions explicitly.


Review Execution

With this example (System/Customer) Requirements tracker configuration in place, we can now start and execute a requirements review.

When executing the Approve transition, you will have to specify the Approvers via the Owner field.




In our example, we choose all project members in role Product Owner.






On the Reviews tab of the resulting screen, we will then see, that there is a new Review for the item in status Waiting for approval in progress:





The designated reviewers are janos and zsolt (those project members in role Product Owner at the time the review was started).

None of the reviewers have reviewed the item yet.


If one of the designated reviewers takes a look at the item to review, e.g. zsolt, there will be a Review action:





Clicking on Review will show a popup dialog, where the reviewer can either Approve or Reject the item.





If plus Role was configured for this review (only CB-10.0 and newer), the user will be also asked to select her/his Role, in which (s)he performs the review.

Depending on the required type of electronic Signature (if any), the user will also have to enter her/his Username and/or password, in order to submit.


In our example, Zsolt rejects the requirement, but because the review allows one reject, this is not decisive yet.





The final decision is for Janos to make, e.g. he will approve:




Because this is the decisive approval (and there is a designated target status and he has appropriate permissions), Janos gets the option to execute the state transition (in this case Accept) to the designated approved status (Accepted) directly.

This completes the review/approval process.





Resolving stuck reviews

There may be situations, where an item review gets stuck, because some of the designated reviewers are not submitting their vote, for any reason.

In this case, users having permission Tracker Admin on the item's tracker, can adjust the review configuration accordingly, by clicking on the review settings icon, right to the review subject:





For example: Reduce the number of required votes: