How to change the workflow of a work item type with existing work items
I have an existing work item type that is using the "Default Workflow". We need to change the workflow to a custom workflow, and have to somehow get all of the existing work items to handle this change.
I can duplicate the existing workflow but it changes the IDs of all the states based on the new workflow ID:
id="APARWorkflow.state.s4"
So then I assume if I go into the Config and change the workflow from Default Workflow to APARWorkflow, basically there will no NO work items that have the correct state visible.
Is there any way to have, within the APARWorkflow, a state called:
"s4" (since this is what I assume is currently stored in the existing work item
and then add an action (temporarily) to change from "s4" to "APARWorkflow.state.closed" which would map it to the right NEW workflow state (since I plan to reduce the states available in the workflow down to just 4 to simplify the workflow).
Or am I really just going to end up with all numbers in the work items and have to go fix them all anyway? I'm wondering what the best practice here is.
Susan
3 answers
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=73309
Comments
Well, not really. It says basically (if I read correctly):
1) that the existing work items will still have the OLD workflow
2) only NEW work items will use the NEW workflow
However, this part:
- If you want to change the workflow for existing work items, do not change the workflow ID or the binding (every work item stores the ID of its workflow), but just change the existing workflow.
.... i can't change the existing workflow, since it is used by other work item types that are still valid.
and
- Make sure that the new workflow is compatible with the old workflow, that is do not remove states and resolutions because old work items may use them already.
.... so this I don't understand. If the old work items will continue to have the OLD workflow saved in them, then why would this matter? And, I don't WANT the older items to continue to have the old workflow and states, since this makes queries extremely difficult.
Susan
The old workitems will only have the old workflow, IF you modify the workflow by duplicating it and binding the new workflow to the WI type, as opposed to modifying the old workflow.
In your scenario, I believe, instead of duplicating the workflow, you'd need to change the existing workflow. Since you are attempting to remove some states, I think you need to make sure no current WIs are in any of the states that you are removing.
Susan, did you ever resolved this issue? I am stuck in a similar situation with 10K+ work items to move to a new workflow. I found another forum discussion that mentioned changing the type and then changing back to reset to workflowSurrogate attribute. But I found that resets the work item state too - not acceptable.
Harry
I didn't really go very far on it. I only had a handful of work items and so manually manipulating them wasn't really that bad. I don't have 10K work items to move to a new workflow.
1. Store user email preferences
2. Silence user emails (has to be done per-user)
3. Reuse code from CopyToProjectAreaOperation.java to modify work item's workflow
4. Restore user email preferences
CopyToProjectAreaOperation.java is found in the com.ibm.team.workitem.rcp.rtc.feature.source_* plugin, com.ibm.team.workitem.rcp.ui_* subarchive, and the com/ibm/team/workitem/rcp/ui/internal/wizards directory. This is enough of the brains behind moving a workitem between project areas that you can play with its copyWorkFlow method. I've adapted it to move workitems between project areas by simply providing a Map that identifies the source workflow ID paired with the target workflow ID.
Even without a comparable set of string identifiers between the project areas, as long as the labels match up you can eventually make that association.
Combine that with a query that pulls the workitems you want to modify in/from the project area, and it should do what you need.
Sam,
After exporting the data and importing it back as per the new workflow, have you checked what happens to the History of the workitem. Whether it is still present or it gets blank??
Comments
the history is lost using export/import.
I have not found a reliable method to recreate the history, short of redoing the operations.
Yeah, even I had the same result.
and even if you could recreate the events, you would still end up with a correct sequence, but the userid and timestamps would be different as there is no effective user impersonation.
we wrote a set of migration utilities to copy a project and its workitems from one server to another with as much fidelity as possible. we spent 100 person days.
and did not get history or plan customization
we estimated another 50-75 person days for those two.. and decided to defer that to a later cycle if ever.
Comments
sam detweiler
May 31 '13, 8:15 a.m.when we did this, we had to export the data, change the template for all the workitems, synchronize, fixup the exported data, then import to make the updates
frederick carter
Dec 15 '13, 4:02 p.m.Sam
can you expound on your solution ?
Susan: does sam's solution address all of your points in your original request and your followup comments ?
sam detweiler
Dec 15 '13, 5:41 p.m.see my other post on using a shared process template. we would find all the impacted workitems (thru a query), export them.
change the process area parent.
then change the export as required (one time a filed changed from checkbox to enum, so we had to fiddle with everything, fixup the export to match.)
then update the existing workitems with the corrections.. sometimes that included a state change.
this is not for the faint of heart.. sometimes the changes are impactful in ways you don't expect.