How to change the workflow of a work item type with existing work items
I've seen a couple posts on this but none that gave me what I think is the final answer ...
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
I think this workitem might contain just what you need:
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=73309 Comments
Susan Hanson
commented May 31 '13, 4:45 a.m.
Well, not really. It says basically (if I read correctly):
Piotr Aniola
commented May 31 '13, 4:58 a.m.
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.
Harry Koehnemann
commented Dec 13 '13, 9:25 a.m.
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.
Please let me know if you found any resolution of workaorund to this problem.
Thanks and best regards,
Harry
Susan Hanson
commented Dec 15 '13, 6:00 p.m.
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.
|
This really should be doable. The general flow is:
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
sam detweiler
commented Sep 01 '14, 7:02 a.m.
the history is lost using export/import.
Rahul Bhoy
commented Sep 01 '14, 7:16 a.m.
Yeah, even I had the same result.
sam detweiler
commented Sep 01 '14, 8:12 a.m.
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.
|
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
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
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 ?
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.