Prevent revision increasment after status change via review center workflow

Christian Junge
edited November 2016 in

Hallo community,

we are using contour to do our formal verification process and we are using the Review Center Workflow to mark all requirements as "released" when the review is finalized.

Our Problem:

A set of req need to be approved in the Review Center: 

- Item 1 Version 1
- Item 2 Version 1
- Item 3 Version 1

All req are now approved in the review. They are all approved in Version 1. When the review is finalized all items are marked as "released" and the Version changes to 2. But the items in Version 2 are not approved.

When I create a Review Center Stats Report after the Review is finalized is shows that the "Reviewed Version" is different from the "Current Version". This happens just a few second after the Review was completed by the approvers.

Question:

Is there a way to  either exclude the Status Change from the Version history or to print out a Report where "Reviewed Version" and "Current Version" are the same?

Is it possible to automatic generate a new Baseline after the Review was finalized?

CJ


Comments

  • Kristina King
    edited June 2016
    Hi CJ,

    This is an interesting problem that you present. Thanks for bringing it up. To answer your questions:
    1. Having a new version created of your items is unavoidable if you use the Review Center Workflow, as no matter what, a change in a pick list field is going to create a new item version. 
    1.1 There is no way to trick the report into showing the same version that is "reviewed" and "current," since it is simply not true. Do you need both of these fields in your report? The Review Center Stats report is a Velocity report, so if you wanted to delve into that you could remove the code that reports on "current version." The root user can access reports and edit the files.

    2. Not that I can think of in the UI, but I wouldn't put it past another user in the community to have a genius workaround.
  • Yves Wernaers
    edited November 2016
    We're experiencing the very same problem. All approvers always reviewed a different revision than the one that is approved. That is very unfortunate.

    I honestly can't find a single reason or example, why a revision should increment when an item gets approved. Since the content of the item does not change, we're only "marking" it as approved.
  • Kristina King
    edited June 2016
    Wernaers, thanks for chiming in. We don't necessarily have a use case for why approval requires a new version; it's just that any field change prompts a new version to be created, and that functionality has not changed in Jama. I think it would be stellar if we introduced a feature that allows particular fields to not increment the version.
  • Christian Junge
    edited March 2016
    Is there a way to see the status of a requirement in the Review Center?
  • Kristina King
    edited June 2016
    An org admin can configure what fields are visible in the Review Center: https://getsatisfaction.com/jama/topics/how-do-i-add-steps-and-other-fields-to-review-center-pqssgnl...
  • We have the same issue. At the end, we have items that have been marked OK in the review, but don't show that in the status. Chaning the status, creates a new version and after getting that change into the review, the OK is lost.
  • Kristina King
    edited June 2016
    This is helpful to know that the version incrementing based on status change is a common problem. Thanks for the added note.
  • Sebastian Theiß
    edited November 2016
    I had a really annoyed JAMA user popping up in my office...
    He had the same problem and another one.

    The standard process for review is:
    - Create specification
    - 1. Review
    - Release
    - Create next revision of the specification
    - 2. Review
    - Release

    When the 2nd review was initiated he had to check the 40 changed requirements and the 960 where the status was changed since the last review. He had to check every item to be sure that not only the status has changed.

    --> possible workaround: Implement a sophisticated filter (like the "new" list view) to filter only requirements that are not released.

    The second problem came up during the second review of a test specification. Also the change of the "Execution Status" leads to a new item version. A unchanged and released test case had to be reviewed again although it was only carried out...

    Is there something on JAMA's road map to fix these issues?

    Cheers,
    Sebastian
  • Harald Hotz-Behofsits
    edited April 2016
    Looks like a plugin could handle that.

    At finishing the review all items being approved with no needs more work should get an update to the desired status.

    Now we jump into a design issue:
    In case a workflow is enabled, it is not easily possible to update, at doing a transition a new version is created, and now again it is outside the baseline.

    There should be in an inversion transition not creating a new version, then it would also work inside a review with a manual bulk action if offered that way.
  • Kristina King
    edited June 2016
    You guys are making my head spin :P

    @Sebastian, no, this isn't currently on the road map (the next change to Review Center you'll see is Relationships), but this topic is gathering steam, so we'll see if it can get prioritized. Ideally we'd allow admins to designate individual fields as not changing the versions...
  • Sebastian Theiß
    edited May 2016
    That sounds like a possible solution. I appreciate a higher prioritization for this topic! ;-)

    Cheers,
    Sebastian
  • Yves Wernaers
    edited November 2016
    Sebastian,
    the way we currently work around your problem is by using a filter to select items to review:
    the filter explicitly exclude all items in Approved state from the review.
    This is fine since we configured Jama to "system lock" all items in approved state so they can not be modified. And our processes do not allow to transition any item from draft to approved except after a successful review.
    Cheers
    yves
  • Jennifer Leitch
    edited July 2016
    Tagging Jackson on this as we are starting to run into questions when we transition our requirements from an Initial Review status to Final Reviewstatus, which then shows as items have changed and clears approvals, when in reality, nothing has changed with the description or the name, just the status field. We'd like to be able to set the status field at the admin level to not trigger as a "change", which requires re-approval.

    Thanks!

    (And HI Kristina!!! I'm baaaack - again!!)
  • Kristina King
    edited July 2016
    Noted! We're tracking this need internally as part of compliance requirements, so hopefully we will see this changed as part of that work.
  • D Dalton
    edited October 2016
    Yep.  We are seeing this also. 
    What might be preferred for versioning the requirement:

    On the Project side-
    Be selective on what changes create a new version, example: only create a new published version show the beginning and end states of the item from a review (Approved to new Approved)?  Is there a way to keep and show an items current state, but not necessarily make it a Version until it hits certain landmarks?

    On the Review side-
    Be able to show a more detailed progression of changes that occur within the review but have the ability to choose what edits flag someone to re-approve, or only require a select group/person to re-approve (like the one that created the comment/issue).  

    We have heard internal feedback that engineering doesn't like having to revisit the reviews and re-approve for things that could take just one engineer's time, or that flag the re-approve of 30 requirements for change on 1 requirement.  And we are concerned that down the road certain requirements will have a TON of versions to look through instead of just the ones that show relevant changes.

    Another Review Center improvement would be a history page, as our previous program included one.  It helps to be able to check in one glance what user made certain changes/comments, republished, closed (by a person or by review end date), etc.  It is another trail that is nice to have, and I would believe the information is there just not being pulled and visable.  Let me know if you would like to see an example and I will send you a screen shot.

    Thanks!
  • Kristina King
    edited July 2016
    dedalton—thank you for this clear explanation of what would work for your organization in terms of versioning changes—that's helpful. I think you make really good points about the inefficiencies and how they can add up. 

    As far as the history of the review center goes, I agree with you on the need for an audit trail (really, I would like to see a trail in every part of the app!). If this is something we consider, I'll make sure we reach out to you.
  • Robena Sukhu
    edited December 2018
    We have had a lot of complaints about the version of the quirements changing when only the status is updated too. Since there is no flag to indicate that only the status was changes, the reviewers/approvers are left wondering if they have the recent requirements or not or whether they need to again action the review.  To avoid the confusion, the BSAs have to send an email to all stakeholders explaining that only the status was changed.

    If anyone has found other workarounds for this, please share it.  Thanks.
    Robena Sukhu
    Sun Life Financial
    ON
    416-496-5456
  • Patrick Eyerich
    edited October 2019

    Hi All,

    We have the very same problem: As soon as a review has taken place successfully, the respective requirements are released by updating their status fields accordingly. This, however, is considered a change in the items and therefore generates new item versions, so the review becomes outdated immediately.

    In my opinion, the correct solution to this problem would be to generally treat the status field differently than the other fields as it is more of a "meta-field": it does not belong to the content of the requirement as the other fields do but rather indicates the current state of the requirement in the respective development process.

    To solve the underlying problem, however, it would be sufficient to allow admins to designate the status field as not changing versions, as proposed.

    Are you currently working on this issue?

    Thanks,
    Patrick

  • Sebastian Merz
    edited April 2020
    Hi @Kristina,
    is it planned to change this behavior in the future?
    As @Patrick said, we are suffering from the current behavior and we would appreciate the possibility to configure the fields that increase the version of an item. 
    Right now our workaround is to set the items to Approved before we start the review but this is not good as well.

    Best regards,
    Sebastian
  • Karen Dorsch
    edited April 2020

    Great idea – we would support this

     



    ------Original Message------

    Hi @Kristina,
    is it planned to change this behavior in the future?
    As @Patrick said, we are suffering from the current behavior and we would appreciate the possibility to configure the fields that increase the version of an item. 
    Right now our workaround is to set the items to Approved before we start the review but this is not good as well.

    Best regards,
    Sebastian
  • Christian Binard
    edited April 2020

    Hi, I do understand the version number increase concern but please don't simply remove the Workflow field from the revision control system: It's our way to trace when an item was approved and in what review (can find the link to the review in the Activity widget Review comment tracking outside of review  posts 15 & 16).

    If you would remove it from revision control, an alternative should be provided to trace back the approving review and its version.

    Possibly the review status may get an hyperlink to the Review version from which the transition was operated.