Rally RPM层次结构范围中的不一致性

我正在创建一个RPM树，可以用来从RPM层次结构的不同级别选择叶故事

通过使用所描述的方法，我能够接近所需的功能，但是在RPM的每个级别上返回的叶故事的数量似乎存在一些不一致

下图显示了该树（出于隐私目的涵盖的项目名称）。黄色徽章显示在RPM层次结构的该级别下找到的叶故事的数量。从图中可以看出，数字不一致。（下面的计划显示了23个叶故事，下面的一个汇总显示了44个叶故事。）事实上，在该汇总下面有44个叶故事，因此问题似乎来自于计划级别的查询

下面是我编写的函数，用于返回所选RPM节点下叶故事的所有OID数组：

                   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([]);
                                    }
                                }
                            }
                        });
                    }

---

这个问题在我看来是正确的。我认为您遇到了一个已知的缺陷，该缺陷存在于回溯API的数据流中。流中的问题已被纠正，但返回并纠正错误历史记录的工作仍在团队待办事项中。如果您希望通过支持跟踪其进度，则该缺陷的ID为DE15647

解决方法（因为您只查询当前数据）是取消受影响项目的父级并重新设置受影响项目的父级

对不起

编辑：关于这个问题的更多细节——在一段时间内，每当一个PortfolioItem（策略、主题、功能、计划）被创建并同时设置了其父项时，Lookback API服务都不会收到新PortfolioItem父项的通知。此问题现已解决，但旧数据仍有待修复。您可以通过查找具有空父字段的_ItemHierarchy中的PI来搜索可能存在此问题的PI

要获取具有空父级（潜在孤儿）的PIs，请执行以下操作：

对于这些“孤儿”，请检查是否有将其作为子女的父母：

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() }
]

fetch:['ObjectID']，
过滤器：[
{property:'Children'，值：currentChild.ObjectID}，
{属性：''U TypeHierarchy'，值：'PortfolioItem'}，
{属性：'_ValidFrom'，运算符：''值：currentChild._ValidFrom.toISOString（）}
]

---

对于每一个快照，如果您找到一个声明子快照的父快照（在创建子快照时），您就知道您有一个受此问题影响的快照，可以通过在ALM中清除其父快照、保存、然后重置其父快照并再次保存来修复此问题。我在第一个检查中包括了_uat:“current”，因为孤儿PI有可能在以后分配了不同的父级，您不想覆盖它。希望这能有所帮助。

这真是一个令人沮丧的问题，尽管它回答了我的问题：为什么有些故事受到影响，而另一些故事没有受到影响。谢谢你告诉我。简单的问题。。。你的意思是重新分配RPM级别、用户情景，还是两者兼而有之？你只需要重新分配RPM级别，因为在流中没有将父级设置为Lookback API。有没有快速或自动的方法？目前，我们的RPM结构中大约有300个节点。手工操作需要花费相当长的时间。我更新了我的答案，提供了更多关于原因和如何识别受影响项目的详细信息。如果调用WSAPI来保存缺少父对象的受影响对象，则应该能够自动执行该操作。

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() }
]