Inconsistencies in RPM hierarchy scoping - rally

Question

I am working to create an RPM tree that can be used to select leaf stories from different levels of the RPM hierarchy.
I was able to get close to the desired functionality by using the method described here, however there appear to be some inconsistencies in the number of leaf stories being returned at each level of the RPM.
The following Image shows the tree (Project names covered for privacy purposes). The yellow badges show the number of leaf stories found below that level of the RPM hierarchy. As you can see from the image, the numbers are inconsistent. (Below the Initiative shows 23 leaf stories and below one of the Rollups shows 44.) There are in fact 44 leaf stories below that Rollup so the problem appears to be from querying at the Initiative level.
Here is the function I wrote which is intended to return an array of all the OIDs for leaf stories below the selected RPM node:
function getDescendants(OID, callback) {
Ext.create('Rally.data.lookback.SnapshotStore', {
autoLoad: true,
pageSize: 1000000,
fetch: ['ObjectID'],
filters: [
{ property: '_ItemHierarchy', value: OID },
{ property: 'Children', value: null },
{ property: '__At', value: new Date().toISOString() },
{ property: '_TypeHierarchy', value: 'HierarchicalRequirement' }
],
listeners: {
load: function(model, data, success) {
if (data && data.length && success) {
var descendants = [];
Ext.Array.each(data, function(story) {
descendants.push(story.get('ObjectID'));
});
callback(Ext.Array.unique(descendants));
} else {
callback([]);
}
}
}
});
}

Answer 1

That query looks correct to me. I think you've encountered a known defect that existed in the data stream to the Lookback API. The problem in the stream has been corrected, but the work to go back and correct the faulty history is still in the team backlog. If you want to track its progress with Support, the defect has ID DE15647.
The workaround (since you're only querying the current data) is to un-parent and re-parent affected items.
Sorry.
Edit: Some more detail on the problem - For a period of time, whenever a PortfolioItem (Strategy, Theme, Feature, Initiative) was created and had its parent set at the same time, the Lookback API service didn't get notified of the new PortfolioItem's parent. This problem is now resolved, but the old data is still to be fixed. You could search for PIs that potentially have this problem by looking for ones in that _ItemHierarchy with a null Parent field.
To get the PIs with null parents (potential orphans):
fetch: ['ObjectID', '_ValidFrom', '_ValidTo'],
filters: [
{ property: '_ItemHierarchy', value: OID }, // only include this if you're limiting to a sub-hierarchy
{ property: '_TypeHierarchy', value: 'PortfolioItem' },
{ property: 'Parent', value: null },
{ property: '__At', value: 'current' }
]
For each of these 'orphans', check for a parent that has it as a child:
fetch: ['ObjectID'],
filters: [
{ property: 'Children', value: currentChild.ObjectID },
{ property: '_TypeHierarchy', value: 'PortfolioItem' },
{ property: '_ValidFrom', operator: '<=' value: currentChild._ValidFrom.toISOString() },
{ property: '_ValidTo', operator: '>' value: currentChild._ValidFrom.toISOString() }
]
For each one, if you find a parent that's claiming the child (at the time the child was created), you know you've a snapshot affected by this problem and can fix it by clearing its parent in ALM, saving, then resetting its parent and saving again. I included __At: 'current' in the first check, since there's a chance the orphaned PI had a different parent assigned later and you wouldn't want to overwrite that. Hope this helps.