What causes an error message like this: "Unable to resolve the planning attribute 'com.ibm.team.apt.attributes._com.ra.team.workitem.attribute.stretch' as work item attribute 'com.ra.team.workitem.attribute.stretch'" in RTC when bring up a plan?
![]() I am using RTC 6.0.4, on iFix 006. In the Web configuration editor (as opposed to hand editing the XML) I added 2 new attributes to my work items and mapped them as plan attributes. I tested to ensure that I could create a plan, and see the attributes in a plan, and then I moved the new process template to production. The architecture is such that child project areas point to a parent project area. It is the parent project area that I updated. When one of the project areas tried to bring up their existing plans while pointing to the newly updated parent project area, the get this message: "(error: Unable to resolve the planning attribute 'com.ibm.team.apt.attributes._com.ra.team.workitem.attribute.stretch' as work item attribute 'com.ra.team.workitem.attribute.stretch'.) " I tried opening the plan of another project area pointing to the same parent, and the plan opens successfully. I added a column to the plan using the new plan attribute. That also worked successfully. I went into the code to verify that the mapping is correct, and everything looks good, which seems to be supported by the fact that I was able to open plans and add the attribute successfully in one of the project areas. Is there anything else that would throw this error, other than an incorrectly mapped attribute?
showing 5 of 8
show 3 more comments
|
One answer
![]() Donald Nong - yes, that is correct. Over the weekend I found out that the child project where I can't open the plans (get the error) has broken inheritance from the parent in several areas (work items - "Types and Attributes", "Editor Presentations", and in Planning - Plan Types, Plan View Elements, and Plan Views). It seems like it has something to do with that, but not exactly sure what. I haven't been able to reproduce it yet. Note: We do not want the child to have broken inheritance and have to fix that. I thought I had a solution to fix it, but now realize I do not because of broken inheritance in the planning part. My solution only took care of the broken inheritance in work items. Don Yang- Thanks. It does exist in the parent, but not in either child. This is what I would expect. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Just to clarify, are you saying that after you made all the changes in the parent/master project area, you could open plans in one child project area, but not in the other?
You can check with source code if the below entry exists:
<attribute
id="com.ibm.team.apt.attributes._com.ra.team.workitem.attribute.stretch"
implementation="com.ibm.team.apt.client.WorkItemAttribute" name="xxxx"
readOnly="false">
<parameters> parameter key="attribute"
value="com.ra.team.workitem.attribute.stretch"/>
</parameters>
</attribute>
in parent or child project
I believe the easiest way to restore the inheritance of the child project is to completely remove the content in the Process Configuration Source tab using the RTC Eclipse client.
Yes, that would be the easiest, I agree. And I was going down that route until I saw that they had broken inheritance on their Plan Views. They have done extensive work on their plan views, and I can't just delete their XML until I can figure out a way to preserve their Plan Views. Any idea how to retain their plan views?
You can try to go through the configuration-data XML blocks and identify the ones that have something to do with work items and delete the whole block until the override is gone. If you look into the section ID's tell you what that belongs to. E.g. id="com.ibm.team.workitem.........." usually means work items.
id="id="com.ibm.team.apt......." would be agile planning.
Take this with a grain of salt: I have never tried that. You probably want to make sure you know the latest version of the XML in the history to be able to go back, or save the whole content, before beginning surgery.
Also, their planning customization will likely refer to the work item configuration, which they changed which might break the plan customization regardless what you do.
Use the final flag in the sharing project area to prevent overriding in the future.
Ralph - I don't think that they intentionally broke the inheritance, so they will not know what they have added. I would like to find out if they changed anything in the work items. Is there a way that I can compare their child XML with the parent (sharing project) XML to see the differences?
The differences are what they have in their overwritten project area XML. You can compare that using your eyes and brain. I am not aware of any other method. You could try to copy paste both XML's into local files and use compare tools e.g. beyond compare. I think there is almost no chance that will help you, though.