RTC Project Export/Import
2 answers
you can export the process config for a project, and create a new template.
using the new template, you can create a new project that will behave exactly like the first.
you cannot 'import' the process config into an existing project however.
This is what the process sharing model is intended to do..
share first projects process config (open project, scroll down, select share)
create New projects with the Unconfigured process template, and then USE the process from the sharing project. (open project, scroll down, select Use, select sharing project)
then whenever you change the sharing project's process, then children get it immediately
by Copying Process XML from Process configuration source and paste in Process source of other project.
Every customization regarding Workitems , workflows etc will be there same as old project.
Comments
this is dangerous. this copies EVERYTHING and OVERLAYS whatever was there.
so you cannot 'add' capabilities.
you will also LOSE any customizations in the receiving project.
but may leave the data in weird states.
I took 'import' to mean selective.
I have also not been particularly successful using the copy xml approach. maybe 5 in 25 tries over the years. there is no way back once you press save on the receiving project. There is no way to backup and restore one project.
1 vote
I agree with Sam's points about the inherent limitations of replacing the XML (for one thing, the XML does not contain the attachments, and those are usually needed as well). But note that the history of all XML versions saved to a project area is kept on the server, so it should be easy for you to "restore" any previous XML.
Except for the data that is changed because of he XML change.. there is no way to fix that (fields added, etc)
The history of the XML is stored on the server and available using the Show History in the project area editor.
However, the XML can be re-arranged when the graphical editors are used to configure permissions, preconditions, etc.
So, it can be not easy to determine which change you want to revert back to.
I, too, agree with Sam that process sharing is the way to go for this scenario.
I assume by "data that is changed because of the XML change", Sam is referring to subsequent explicit changes to work items (i.e. after the new XML is saved), which will be based on the new XML. Reverting back the XML does not have any effect on those work items, so they might refer to properties or states that do not appear in the original XML. But if no changes are made to any work items while the new XML is in place, you can restore the previous XML, and things should now work exactly as they did before you updated the XML.