How can I close this "hole"?
We've come across an interesting "hole" that I have been asked to close.
In a few work item types, we do not allow the work item to be Reopened once it gets to a ClosedStateGroup. Each of our work items has a custom work flow.
We've found the case where if you've a work item (e.g. Defect/Task) that's been closed and you'd like to re-open (which is NOT allowed by the available workflow actions), you can do it in a back-door fashion by changing the Type of the Cancelled/Closed work item then Save. This ends up moving the work item to Open. Then you just change the type again back to what it was before and you get a Reopened work item even though we didn't provide a Reopen action.
I think I know *why* this occurs (object has workflow literal, which doesn't exist in the custom workflow of the new work item type, so it gets nulled out, which default to the InitializeAction).
First question is .. is this an RTC bug? A design point? A bad side-effect of our using different custom workflows?
Second question is ... can I close the whole without using the same workflow, and without restricting all of my team from the ability to change work item types?
Susan
In a few work item types, we do not allow the work item to be Reopened once it gets to a ClosedStateGroup. Each of our work items has a custom work flow.
We've found the case where if you've a work item (e.g. Defect/Task) that's been closed and you'd like to re-open (which is NOT allowed by the available workflow actions), you can do it in a back-door fashion by changing the Type of the Cancelled/Closed work item then Save. This ends up moving the work item to Open. Then you just change the type again back to what it was before and you get a Reopened work item even though we didn't provide a Reopen action.
I think I know *why* this occurs (object has workflow literal, which doesn't exist in the custom workflow of the new work item type, so it gets nulled out, which default to the InitializeAction).
First question is .. is this an RTC bug? A design point? A bad side-effect of our using different custom workflows?
Second question is ... can I close the whole without using the same workflow, and without restricting all of my team from the ability to change work item types?
Susan
Comments
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Apr 11 '14, 4:03 a.m.Susan,
with respect to bug, for all I know this is as designed. It always worked this way and on purpose. If you change work item types and there is no matching state, you need to get a valid state.
As how to fix it, why not creating an advisor that prevents changing the work item type if the work item state is in a closed state group?
Susan Hanson
Apr 11 '14, 4:20 a.m.Yea, I was hoping there was a way without me writing an advisor but that was my next choice down.