1

RPM階層のさまざまなレベルからリーフストーリーを選択するために使用できるRPMツリーの作成に取り組んでいます。

ここで説明する方法を使用することで、目的の機能に近づくことができましたが、RPMの各レベルで返されるリーフストーリーの数にいくつかの不一致があるようです。

次の画像はツリーを示しています（プライバシー保護の目的でプロジェクト名がカバーされています）。黄色のバッジは、RPM階層のそのレベルの下で見つかったリーフストーリーの数を示しています。画像からわかるように、数字は一貫していません。（イニシアチブの下には23枚のリーフストーリーが表示され、ロールアップの1つの下には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([]);
                                    }
                                }
                            }
                        });
                    }
4

1 に答える 1

2

そのクエリは私には正しいように見えます。LookbackAPIへのデータストリームに存在する既知の欠陥に遭遇したと思います。ストリームの問題は修正されましたが、戻って障害のある履歴を修正する作業は、チームのバックログに残っています。サポートで進行状況を追跡する場合、欠陥のIDはDE15647です。

回避策（現在のデータのみをクエリしているため）は、影響を受けるアイテムの親を解除して再親にすることです。

ごめん。

編集：問題の詳細-一定期間、PortfolioItem（戦略、テーマ、機能、イニシアチブ）が作成され、同時に親が設定された場合、LookbackAPIサービスは通知を受け取りませんでした。新しいPortfolioItemの親。この問題は現在解決されていますが、古いデータはまだ修正されていません。_ItemHierarchyで親フィールドがnullのPIを探すことで、この問題が発生する可能性のあるPIを検索できます。

nullの親（潜在的な孤立）を持つPIを取得するには：

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' }
]

これらの「孤児」のそれぞれについて、それを子として持っている親を確認します。

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

それぞれについて、（子が作成された時点で）子を要求している親を見つけた場合、この問題の影響を受けたスナップショットがあることがわかり、ALMでその親をクリアし、保存してからリセットすることで修正できます。親と再度保存します。孤立したPIに後で別の親が割り当てられた可能性があり、それを上書きしたくないため、最初のチェックに__At：'current'を含めました。お役に立てれば。

于 2013-01-09T20:50:53.363 に答える