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
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).
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).
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.
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.
Comments
Karl Todd
Jul 24 '15, 3:43 p.m.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.
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jul 24 '15, 3:34 a.m.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.