How to fix broken inheritance due to configuration of Work Items in the child project ?
We are using a highly customized process template in the master project, with the idea of using inheritance, from the master, for a child project.
Some smart-Alec however, went in and configure WIs in the child project, hence broke the inheritance. Maybe it was not a smart-Alec after all but just somebody blind to the warnings whenever an attempt is made to configure anything in the child project.
Can the broken inheritance be fixed:
-
By just marking
in the master project in all WIs configurations or in those mis-configurations. (for us Permissions and WI attribute customization on PROD server/ Types & Attributes, Attribute Customization, and Editor Presentations on DEV server).
- Or by wiping out all the mis-configurations in the child project ? Would that bring the configurations back to the pristine conditions prior to any configuration ?
2 answers
Hello,
yes - in the master / parent PA, flag as final anything that should not be overridden in child PA(s).
https://jazz.net/help-dev/clm/topic/com.ibm.jazz.platform.doc/topics/c_sharing_project_area_process_web.html
And Sam is right - clearing all in the child PA's XML will fix your current issue.
Thanks,
Eric
We may have stumbled onto a perfect/accurate way, albeit maybe tedious for child projects suffering broken inheritance too long and/or there have been too many changes between first break and fix, to fix broken inheritance; ironically long after we have a chance to work in an env with inheritance in use, let alone to have broken inheritance to fix.
Had seen (PA) history used to recover broken process specs directly edited, but always thought there was only one or two backup copies, or was it actually so in 3.x ? Only realized today in 5.0.2 that process specs are kept a copy per change probably indefinitely back to initial one. Any automatic periodical purges ?
Regardless, we may have a good chance to back track history to just prior to inheritance breakage, pick up that process specs to replace the current for the child project area of concern. Then we recreate all changes to that child PA on the parent.
That should be a very accurate fix with of course some obstacles to overcome:
- Multiple broken children PA's may have had conflicting modifications.
- And Sam's discovery still true "BUT, whatever they added will still be in existence in those workitems and in the database forever", unless somehow, or with some tweaks, or with a miracle in current implementation, same customized attributes, now allowed with same name, no longer in existence in the child PA, can be created with same UUID to reconcile old WIs for maintenance.
Comments
sam detweiler
Jan 06 '14, 8:22 p.m.As I recall from doing this last year, if u delete all the process XML, you will get back to the parent. BUT, whatever they added will still be in existence in those workitems and in the database forever. And will show in query editor. And you will lose the ability to do any maint on those fields.