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 |
Accepted answer
U would have to write a plugin and detect the previous state/type is different and reject it.
Then another to allow it, and assign to specific role only
Susan Hanson selected this answer as the correct answer
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
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?
Yea, I was hoping there was a way without me writing an advisor but that was my next choice down.