0

The lookback api docs say PortfolioItem field is an index. Is the lowest portfolio item type also an index?

E.g: the Portfolio Item types in my workspace are Product, Milestone and Feature. will Feature be an index in Lookback API in addition to PortfolioItem?

The reason I ask is because only top-level UserStories have the PortfolioItem field, but both top-level and child UserStories have the Feature field. I want to query all User Stories under a particular Feature, which means I can't use PortfolioItem field, because it will not include child User Stories, only top-level User Stories.

Example of what i want to do if Feature is indexed:

    Ext.create('Rally.data.lookback.SnapshotStore', {
        listeners: {
            load: function(store, data, success) {
                //do stuff
            }
        },
        autoLoad:true,
        limit:Infinity,
        fetch: ['ScheduleState', 'PlanEstimate', 'Feature', 'ObjectID'],
        compress:true,
        find: { 
            _TypeHierarchy: 'HierarchicalRequirement', 
            Children: null,
            Release: //a release OID
        },
        hydrate: ['ScheduleState']
    });
spsteffl
  • 413
  • 3
  • 11

2 Answers2

1

The _ItemHierarchy field includes all levels of PortfolioItems through all levels of Stories to Defects, Tasks and (I'm pretty sure) TestCases. So, if you want "all User Stories under a particular Feature", simply specify find: {_ItemHierarchy: 1234567} where 1234567 is the ObjectID of the Feature. You could combine this with the _TypeHierarchy and Release clauses. If you combine it with the Children and _TypeHiearchy clauses as you proposes, that will give you only leaf stories as opposed to all the levels. This is ideal if you are doing aggregations on fields like sum of PlanEstimate (points) or TaskActual, etc.

Note, I don't think this has anything to do with being indexed, so I may be misunderstanding your question. Please accept my apology if that's the case.

Larry Maccherone
  • 9,393
  • 3
  • 27
  • 43
  • Thanks for the response! I took a look at your solution in my code, but it is not best suited for what I'm trying to do, it was too slow. I have ~20 projects, and ~70 features, so I cannot be sending a 1400 requests for lookback data. Instead, I want to just make ~20 requests (1 for each project). Additionally, I needed to get UserStories not attached to Features as well, so your solution would require extra logic for that. – spsteffl Apr 06 '15 at 23:14
  • _ProjectHierarchy is not optimal as well – spsteffl Apr 06 '15 at 23:15
  • Do you have 70 features total? or approximately 70 per project? If it's the former, then you only need to make 70 calls. Unlike the standard WSAPI, the LBAPI is not automatically Project scoped. Note, there may be some logic in the App SDK SnapshotStore that automatically adds Project scoping but I'm sure there is a way to turn that off. IMHO, I find the SnapshotStore to be less than ideal because it was written to be consistent with the rest of the App SDK which is almost completely about accessing the standard WSAPI rather than written to support the very different paradigms of the LBAPI. – Larry Maccherone Apr 07 '15 at 03:34
  • Alternatively whenever I have a situation like the one you describe, my approach is to get the big dump once and then incrementally update it. The LBAPI is ideal for this approach since the old data is never changed, just new data added. Let me know if you are interested in that and I'll point you to some libraries designed to do that. – Larry Maccherone Apr 07 '15 at 03:38
  • Actually, if it's 70 features total, you can put them together into one big $in clause and do the entire thing in one call. Even if you have 70 per 20 projects, you could do the entire thing with 20 calls total. – Larry Maccherone Apr 07 '15 at 03:40
1

There may be some confusion with the use of the word 'index'. Some fields are "indexed" for fast lookup..."Feature" isn't one of them, though it is a valid field and you can search for it. More correctly, the field that is the lowest-level Portfolio Item type is kept in the snapshots.* Given what you're asking for, adding "Feature": {oid} to the find should give you what you want.

* The distinction is due to the fact that the label "Feature" can be changed to something else, so what is "Feature" in one workspace might be "Thing" in another.

Joel Sherriff
  • 478
  • 2
  • 6
  • Yeah i am aware that 'Feature' can be other things, which is why I worded it: the portfolioItems 'in my worksapce'. I know Feature is valid, but I did not know if it was 'indexed for fast lookup', which was what my question was asking -- and you answered. – spsteffl Apr 07 '15 at 15:56