Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 317285

Summary: Blocking review still blocks transition if associated state is changed
Product: [Technology] OSEE Reporter: Mark D-B <mark.db>
Component: Action Tracking System (ATS)Assignee: Project Inbox <osee.ats-inbox>
Status: NEW --- QA Contact:
Severity: normal    
Priority: P3    
Version: 0.9.1   
Target Milestone: 0.9.5   
Hardware: All   
OS: All   
Whiteboard:

Description Mark D-B CLA 2010-06-18 07:23:05 EDT 
I'm not sure if this is a bug, or an enhancement request.

We have a use case where we'd like to be able to allow a transition one state forward where a review is active. I was holding fire on submitting an enhancement request for that because there's already a lot going on at the moment, and I thought I had a workaround.

Here is the workaround use case that shows up this bug (feature?):

The state "IntentReview" creates a peer-to-peer review on entry, which is set to block the transition. The review is set up, and moved from prepare to review. Reviewers enter their comments, and the review takes place.

Now, if their are only minor changes required, we don't want to go back to the previous state and then do another review, so we have an optional next state (which is skipped if their are no changes required) "ReviewActions". The idea is to stay in this state until the minor changes have been moderated.

Because the peer-to-peer review blocks the transaction, we can't get to "ReviewActions". So, I added the "Related To State - ats.Related To State" widget to the review state of the peer-to-peer review.

I can now change the related state from "IntentReview" to "ReviewActions".

When I save this, and then open the workflow, the blocking review is no longer shown as an error on the "IntentReview" state. Great, I think, I can do what I want. However, attempting to make the transition to "ReviewActions" yields the "Transition Blocked" Dialogue.

Either it should allow the transition (intuitive, because the blocking state has been changed) or the error and blocking review annotation should still appear in the old state's information.