It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,875
×6,109
×89
×24

question asked: Jun 04 '13, 8:11 a.m.
question was seen: 4,946 times
last updated: Apr 29 '14, 8:11 a.m.

Related questions

Collapsing work item states

1
Bill Higgins (456●25●23) | asked Jun 04 '13, 8:11 a.m.
JAZZ DEVELOPER
On my project we have about ten different work item types and many of them have similar workflows. Because of the way people created the new work item types over time, we have several workflow states that are logically the same but treated as different values from a work item query perspective.

For instance, if I create a query and add the "Status" attribute, I see the following values simply for the logical "New" state:

New (Epic Workflow)
New (User Story Workflow)
New (Feature Request Workflow)
New (Plan Item Workflow)
New (Task Workflow, Defect Workflow)
New (Impediment Workflow)
New (Retrospective Workflow)

As an experiment, I manually edited the process configuration source for a rarely used state ("Deferred") and was able to replace the duplicate logical states with a single state (basically by ensuring that both workflows referenced the same state ID). I then did a bulk work item update to update all work items with the old Deferred to the new Deferred and finally removed the old Deferred states.

The result is that I now see this in the work item query editor for Deferred:

Deferred (User Story Workflow, Epic Workflow)

... which is just fine.

My question is this: Is there any downside to performing this clean-up for every work item state that has logical duplicate states? I can only think of two:
  1. Queries referencing the old states will function incorrectly
  2. If I ever want to rename a state for a single workflow, I will have to perform a reverse refactoring for that workflow
I can handle #1 just via communication. I can live with the unlikely potential annoyance of #2. Anything else?

-----

PS - For your reference, here is my approach for making the change:
  1. In the process UI, append " (Old)" all of the duplicate states (e.g. "Deferred" becomes "Deferred (Old)")
  2. Choose a semantically meaningful ID for the consolidated state (e.g. "myproject.workflow.state.deferred")
  3. In the process configuration source, for each workflow using the redundant states, make the following changes:
    1. Duplicate the <state> definition (including sub-elements) for the "(Old") version of the state, strip "(Old)" from the dup and give the dup semantically meaningful ID
    2. Update any <action> elements that target the old state ID to target the new ID
    3. For the old <state> definition, add an <action> subelement that allows you to transition to the new state; usually you can just copy and paste this from one of the other <state> definition that naturally transitions to the target state
  4. Save the process spec (first time)
  5. Create and run a saved query that shows all work items matching any of the old states
  6. Perform bulk updates as necessary to transition the work items to the new consolidated state; e.g. at first you would have a column full of "Deferred (Old") and later "Deferred"
  7. After updating all work items, in the process UI, remove each of the "(Old)" state definitions, initially choosing "Just show affected items" to ensure you didn't miss any
  8. Save the process spec (second time)
Comments
Susan Hanson commented Apr 29 '14, 2:20 a.m.

Bill, have you implemented this and if so, have you seen any issues?  We are looking at doing some "simplifications" in our workflows and would like to do somewhat of the same ... have a 'Common New' which is used for all workflows so that we only have 1 "New" in the Query Builder as all workflows would use the same ID.  So instead of something defectWorkflow.state.s2 and aparWorkflow.state.s7 and taskWorkflow.state.s3 ... we would have common.state.new as the ID (by manually editing the process XML) that is used in all Workflows as the initial state.

Bill Higgins commented Apr 29 '14, 8:11 a.m.
JAZZ DEVELOPER

Hi Susan, yes I implemented this and it worked great, other than sending out many confusing emails to people.

One answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Stephanie Bagot (2.1k●1●5●13) | answered Jun 04 '13, 11:33 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
We don't typically recommend changing the process configuration source, but based on your requirement, this is the only option. The only problem which may arise is that if you have work items stuck in state A and change that state ID to match state B. Those work items will be stuck in 'no mans land' and not have a logical path to move to the next state.

To avoid this, make sure that no work items are in the state you are changing.
First, move them into a new 'intermediary' state and then back into that state (you will need to configure a bunch of different workflow actions for this).

Just be careful when changing the source and make the changes one at a time so that you can easily revert back to the previous process template and recover from any issues.

Your answer

Register or to post 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.