It's all about the answers!

Ask a question

How to fix broken inheritance due to configuration of Work Items in the child project ?


long TRUONG (363487129) | asked Jan 06 '14, 6:53 p.m.
 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 ?

Comments
sam detweiler commented 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.

2 answers



permanent link
Eric Jodet (6.3k599120) | answered Jan 07 '14, 5:24 a.m.
JAZZ DEVELOPER
 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
 

permanent link
long TRUONG (363487129) | answered May 14 '15, 8:26 a.m.
edited May 14 '15, 8:28 a.m.
 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.

Your answer


Register or to post your answer.