Is id="s3" required for closing state in Workflows
![]()
Our Defect Workflow has an issue when even when our closing state is listed in the Closed state group, it still appears in queries when the Unresolved checkbox is checked. I noticed that all the out-of-the-box Work Item types have "s3" as the id for the closing states so maybe when I switched the Defect Workflow's closing state to a different ID this problem occurred.
I also noticed that on my test system where the Defect Workflow is working correctly that the id for our Closed state is "s3". But the production machine where it's "s2" does not. The Source code below shows a few of our State groups for the Defect Work Item. Notice that Closed is "s2" and Returned is "s3". When I run a query using the Status field, both States appear in Unresolved and Resolved. But if I switch Closed to s3, it only appears in Resolved as expected. It's odd but it seems like it's currently appearing in both because it's in the Closed State Group and not "s3". And vice-versa Returned is appearing in both because it's in the In Progress State Group but also "s3" which makes it appear in the Resolved group. Is this a known issue? I'm wary of switching the ID permanently because there's several thousand closed records I'd have to modify. <state group="closed" icon="processattachment:/workflow/close.gif" id="s2" name="Closed" showResolution="true"> <action id="com.ibm.team.workitem.defectWorkflow.action.reopen"/> </state> <state group="open" icon="processattachment:/workflow/open.gif" id="s1" name="Open" showResolution="false"> <action id="com.ibm.team.workitem.defectWorkflow.action.a2"/> <action id="com.ibm.team.workitem.defectWorkflow.action.a3"/> <action id="com.ibm.team.workitem.defectWorkflow.action.a4"/> <action id="com.ibm.team.workitem.defectWorkflow.action.a5"/> </state> <state group="open" icon="processattachment:/workflow/reopen.gif" id="s6" name="Reopened" showResolution="false"> <action id="com.ibm.team.workitem.defectWorkflow.action.a2"/> <action id="com.ibm.team.workitem.defectWorkflow.action.a3"/> <action id="com.ibm.team.workitem.defectWorkflow.action.a4"/> <action id="com.ibm.team.workitem.defectWorkflow.action.a5"/> </state> <state group="inprogress" icon="processattachment:/workflow/reiterate.gif" id="s3" name="Returned" showResolution="true"> <action id="com.ibm.team.workitem.defectWorkflow.action.reopen"/> <action id="com.ibm.team.workitem.defectWorkflow.action.a5"/> </state> |
2 answers
![]() Our Defect Workflow has an issue when even when our closing state is The problem is that you have "s3" in the 'inprogress' group for the Defect Workflow. And other workflows use the same ID "s3" for a state in the 'closed' group. In the DB, only "s3" is stored, without any workflow context. A query for 'Resolved' gathers all states in the 'closed' group (across workflows), finds "s3" and queries for it. This will also find the 'inprogress' items that also use "s3" for their state id. In short: State IDs should be unique across workflows, unless they represent the same state. -- Regards, Patrick Jazz Work Item Team |
![]() Our Defect Workflow has an issue when even when our closing state is The problem is that you have "s3" in the 'inprogress' group for the Defect Workflow. And other workflows use the same ID "s3" for a state in the 'closed' group. In the DB, only "s3" is stored, without any workflow context. A query for 'Resolved' gathers all states in the 'closed' group (across workflows), finds "s3" and queries for it. This will also find the 'inprogress' items that also use "s3" for their state id. In short: State IDs should be unique across workflows, unless they represent the same state. -- Regards, Patrick Jazz Work Item Team Thanks Patrick. Is there a recommended process to modify the ID when I have thousands of records in the Closed state already? When I change the Closed state from "s2" to "s3" all the Closed records are going to change. Should I just do a mass update of the State after I change the ID value? |
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.