how to migrate local process changes to parent using delta config, help
we cannot get to 4.0.1 fast enough, so we have to deploy some fields into child(consumer) projects now.
these might be manageable later with the deltaconfiguration stuff published in 4.0.1.. but my limited testing tells me once we break a config section away from the master there is no way back..
I need to try this, but.. if I parent the consumer project to a NEW master, do I get to start fresh? I know the data is there already, but can I pick it up with delta config statements?
if I keep the same parenting the answer is no.. I tested that already..
but when I change the master process config..
the ids of the config data would be identical. to the actual data. and we are quibbling about which area of the process config data they come from..
the question is, is the disconnected flag for each section reset when u reparent?
these might be manageable later with the deltaconfiguration stuff published in 4.0.1.. but my limited testing tells me once we break a config section away from the master there is no way back..
I need to try this, but.. if I parent the consumer project to a NEW master, do I get to start fresh? I know the data is there already, but can I pick it up with delta config statements?
if I keep the same parenting the answer is no.. I tested that already..
but when I change the master process config..
the ids of the config data would be identical. to the actual data. and we are quibbling about which area of the process config data they come from..
the question is, is the disconnected flag for each section reset when u reparent?
3 answers
my attempt to test this has run into trouble..
I created a new parent(P), then created a new project (A), created a local enum, attribute,presentation, created a workitem(14). selected data from the enum, all is ok.
then I created a NEWER project (P1) from the same template, with the field still missing (enum, attribute, presentation)
then I reparented project A using the new project (P1).
the fields in the workitem 14 for the local data appear on the Custom tab.. as expected
now I want to use the delta-config to define the local fields..
do one at a time
enum first
<configuration-data-delta configuration-data-id="com.ibm.team.workitem.configuration.enumerations">
<add-element>
<addition>
<enumeration attributeTypeId="com.id.workitem.enum.featurelist" name="Featurelist">
<literal default="true" null="true" id="com.id.workitem.enum.literal.l2" name="unassigned"/>
<literal id="com.id.workitem.enum.literal.l4" name="test1" externalValue="test1"/>
<literal id="com.id.workitem.enum.literal.l6" name="test2" externalValue="test2"/>
</enumeration>
</addition>
</add-element>
</configuration-data-delta>
this saves without error.. switching back to the non-source process config view however shows as below, which seems to indicate some problem.
I created a new parent(P), then created a new project (A), created a local enum, attribute,presentation, created a workitem(14). selected data from the enum, all is ok.
then I created a NEWER project (P1) from the same template, with the field still missing (enum, attribute, presentation)
then I reparented project A using the new project (P1).
the fields in the workitem 14 for the local data appear on the Custom tab.. as expected
now I want to use the delta-config to define the local fields..
do one at a time
enum first
<configuration-data-delta configuration-data-id="com.ibm.team.workitem.configuration.enumerations">
<add-element>
<addition>
<enumeration attributeTypeId="com.id.workitem.enum.featurelist" name="Featurelist">
<literal default="true" null="true" id="com.id.workitem.enum.literal.l2" name="unassigned"/>
<literal id="com.id.workitem.enum.literal.l4" name="test1" externalValue="test1"/>
<literal id="com.id.workitem.enum.literal.l6" name="test2" externalValue="test2"/>
</enumeration>
</addition>
</add-element>
</configuration-data-delta>
this saves without error.. switching back to the non-source process config view however shows as below, which seems to indicate some problem.
Comments
Hi, Sam. This is the expected behavior. The Eclipse editor is just trying to tell you that there is no UI for deltas yet. You need to edit the XML (as you've been doing).
If you want to see what the effective (merged) configuration looks like - the parent process plus your delta in the child - you can do this by opening the workitem configuration in the web UI. We know this isn't ideal, but it gives you a way to see the effective configuration.
For deltas, the situation is basically:
Eclipse client - view/modify the raw delta itself
Web UI - view the effect of the delta applied to the parent, read-only
thanks. will ignore the dark message,,
but I didn't get the results I expected.. the workitems don't have the fields I created with the delta xml..
this forum tool needs a '<code> block element
this to me says, add an enumeration, add an attribute to hold it, and put it on the screen after the Category field.
in the defect record. (where ever default editor is).. this is cut/paste of the text here
https://jazz.net/wiki/bin/view/Main/ConfigurationDataDeltaUserDoc
but the field does appear on the custom tab.. so I must have misunderstood how to specify presentation placement
<code>
<configuration-data-delta configuration-data-id="com.ibm.team.workitem.configuration.workItemTypes">
<add-element>
<addition merge-depth="1">
<customAttributes category="com.ibm.team.workitem.workItemType">
<customAttribute id="com.xx.id.workitem.attribute.feature" name="Feature" type="com.xx.id.workitem.enum.featurelist"/>
</customAttributes>
</addition>
<addition merge-depth="1">
<attributeDefinitions>
<attributeDefinition id="com.xx.id.workitem.attribute.feature" name="Feature" type="com.xx.id.workitem.enum.featurelist"/>
</attributeDefinitions>
</addition>
</add-element>
</configuration-data-delta>
<configuration-data-delta configuration-data-id="com.ibm.team.workitem.editor.configuration.presentations">
<add-element>
<path>
<section id="com.xx.tools.workitem.section.details">
<presentation attributeId="com.ibm.team.workitem.attribute.category"/>
</section>
</path>
<addition location="after">
<presentation attributeId="com.xx.id.workitem.attribute.feature"
kind="com.xx.id.workitem.enum.featurelist"/>
</addition>
</add-element>
</configuration-data-delta>
</code>
here is the parent presentation section
<code>
<section id="com.xx.tools.workitem.section.details">
<presentation attributeId="com.ibm.team.workitem.attribute.workitemtype" kind="com.ibm.team.workitem.kind.enumeration"/>
<presentation attributeId="com.ibm.team.workitem.attribute.category" kind="com.ibm.team.workitem.kind.internal.category"/>
<presentation attributeId="com.ibm.team.workitem.attribute.severity"
kind="com.ibm.team.workitem.kind.enumeration"/>
</code>
it appears correctly, on the wrong tab. so the enum, and the variable are correct, and the structure of the presentation is right.. just the anchor appears wrong..
this to me says, add an enumeration, add an attribute to hold it, and put it on the screen after the Category field.
in the defect record. (where ever default editor is).. this is cut/paste of the text here
https://jazz.net/wiki/bin/view/Main/ConfigurationDataDeltaUserDoc
but the field does appear on the custom tab.. so I must have misunderstood how to specify presentation placement
<code>
<configuration-data-delta configuration-data-id="com.ibm.team.workitem.configuration.workItemTypes">
<add-element>
<addition merge-depth="1">
<customAttributes category="com.ibm.team.workitem.workItemType">
<customAttribute id="com.xx.id.workitem.attribute.feature" name="Feature" type="com.xx.id.workitem.enum.featurelist"/>
</customAttributes>
</addition>
<addition merge-depth="1">
<attributeDefinitions>
<attributeDefinition id="com.xx.id.workitem.attribute.feature" name="Feature" type="com.xx.id.workitem.enum.featurelist"/>
</attributeDefinitions>
</addition>
</add-element>
</configuration-data-delta>
<configuration-data-delta configuration-data-id="com.ibm.team.workitem.editor.configuration.presentations">
<add-element>
<path>
<section id="com.xx.tools.workitem.section.details">
<presentation attributeId="com.ibm.team.workitem.attribute.category"/>
</section>
</path>
<addition location="after">
<presentation attributeId="com.xx.id.workitem.attribute.feature"
kind="com.xx.id.workitem.enum.featurelist"/>
</addition>
</add-element>
</configuration-data-delta>
</code>
here is the parent presentation section
<code>
<section id="com.xx.tools.workitem.section.details">
<presentation attributeId="com.ibm.team.workitem.attribute.workitemtype" kind="com.ibm.team.workitem.kind.enumeration"/>
<presentation attributeId="com.ibm.team.workitem.attribute.category" kind="com.ibm.team.workitem.kind.internal.category"/>
<presentation attributeId="com.ibm.team.workitem.attribute.severity"
kind="com.ibm.team.workitem.kind.enumeration"/>
</code>
it appears correctly, on the wrong tab. so the enum, and the variable are correct, and the structure of the presentation is right.. just the anchor appears wrong..
well, I went back and cut/pasted the same text over again , and now it works!!
parent A, has enum X/attribute/presentation
child of parent A, customizes enum X, enum section breaks away
parent B, removes enum X/attribute/presentation, as intended to be overridden in client
updates enum Y with another value for all clients
child of parent A, now made to be child of Parent B.
delete process xml (the breakaway copy)
add delta config for definition of child representation of enum X/attribute/presentation
synchronize attributes for all existing workitems
open existing worktitem, custom data appears with prior selection of enum
open new workitem, delta config custom data appears
update delta config
open new workitem, new delta config
open existing workitem, no delta config update
synchronize attributes existing workitems
open existing workitem
update delta config present.
THIS is ENORMOUS news.. we can recover from breakaway!!!!..
please please, document this as the case and support it while you build the rest of the delta config support.
now there is a BAD side too.. if you have a child that breaks away, and you delete the process config and add the delta that overlaps/duplicate the (existing or new) parent.. you get a MERGE of both so you get TWO fields on the presentation AND in the enum case, BOTH merged together.. quite ugly!!
parent A, has enum X/attribute/presentation
child of parent A, customizes enum X, enum section breaks away
parent B, removes enum X/attribute/presentation, as intended to be overridden in client
updates enum Y with another value for all clients
child of parent A, now made to be child of Parent B.
delete process xml (the breakaway copy)
add delta config for definition of child representation of enum X/attribute/presentation
synchronize attributes for all existing workitems
open existing worktitem, custom data appears with prior selection of enum
open new workitem, delta config custom data appears
update delta config
open new workitem, new delta config
open existing workitem, no delta config update
synchronize attributes existing workitems
open existing workitem
update delta config present.
THIS is ENORMOUS news.. we can recover from breakaway!!!!..
please please, document this as the case and support it while you build the rest of the delta config support.
now there is a BAD side too.. if you have a child that breaks away, and you delete the process config and add the delta that overlaps/duplicate the (existing or new) parent.. you get a MERGE of both so you get TWO fields on the presentation AND in the enum case, BOTH merged together.. quite ugly!!