RTC Move/Copy from one project area to another.
Hi All.
We are a week any from rolling out a process that involves 4 RTC ccm projects. Each project contains the same work items but values had to be highly customized for each project, that is why process sharing did not work for us. However, We intended to be able to move work items around each project as necessary.
I have been looking online for information about what is required to move a work item from one project to another. Especially when it comes to custom work items and attributes. But have not found anything useful.
It seems the rules are as follows:
Workitem id (not just the workitem name) must match in all projects or the first work item defined in the "to" project will be used as default.
For attributes, ALL of the following MUST match:
Attribute name:
attribute ID:
attribute type:
If they do not match then no match attribute is found the data is not transferred.
Changing the attribute id in the process configuration source seems to not work.
For attributes with enumerations:
It must find a matching enumeration id or it will be mapped (changed) to unassigned.
Example:
id="priority.literal.l02" name="Low" would NOT match to id="priority.literal.l16" name="Low" Even thou by name "Low" is defined in both projects.
Example 2:
id="priority.literal.l02" name="High" would match to id="priority.literal.l02" name="420" but would be wrong.
This seems to be the most manageable as we can sync the ids in the process configuration source then reselect the named value in the workitem.
We want to avoid a maintenance nightmare and still have a seamless flow from projects.
Any suggestions?
|
3 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Jul 23 '15, 2:59 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Jul 24 '15, 5:45 p.m.
In general, you cannot "change" the ID of anything. The ID is by definition what distinguishes "this" instance of an object from some "other" instance of an object.
So in particular, you cannot "change" the ID of a work item. You can modify the fields of a work item (which is what happens when you "move" a work item from one project area to another", or you can create a copy of a work item (which will then have a different ID). So for example, if you export a set of work items, and then modify the "ID" field in the XML, and then re-import that XML, you are not "modifying the ID of that work item", but rather you are specifying a different work item, that happens to have the same value in some (or all) of its fields, i.e. creating a copy. Similarly, when you change the "ID" of something defined in the process XML, what you are really doing is creating a "copy" of that object (which has a different ID). But you also have effectively "deleted" the original object from the process XML, so any existing object in the database that refers to that process element (attribute definition, whatever) will "not find" that object (and that is when you get those ID's showing up in the GUI, which is how RTC tells you that it cannot find the definition of that process element). |
Hi Nannette,
Please find the RFE details below and vote for it. https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=89392 Refer the wiki below. https://jazz.net/wiki/bin/view/Main/BulkMoveWorkItemsBetweenProjectAreasInRTC4 Regards, Arun. |
Ralph Schoon (63.1k●3●36●46)
| answered Jul 23 '15, 4:08 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
It looks like the ID will be kept if you move. The ID is unique per repository, so because the ID is only used by this work item, it can be kept.
If you move/copy across project areas and the copy can not map the content of attributes, because the process and workflow and attribute/attribute value ID's are totally different, you will loose information. The move/copy tells you what could not be matched and you will have to manually change the values. I am not sure what your question really asks for. |
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
It seems the question is:
Can ids like work item id, attribute id, enumeration ids. be changed in the process configuration source after they have been set initially? Or is this not a recommended thing to do?
If the recommendation is to recreate all of the projects so all of the id can be synced, this should be done before they roll out the projects into production.
It seems the work item id is the big unknown.
To make the copy/move successful, you have to make sure the processes have a big overlap in ID's and literals. This has to happen before the process is deployed from the template - e.g. by customizing it in a throw away test server. If the ID's are given, it is too late. If you change ID's in the process XML and the ID's have been used already, you loose the connection to the existing data and might damage your project area beyond repair.