I have a WSAPI query that returns a number of stories. For each of these stories, I'd like to inspect the "root" parent. So I make the query, and in the "fetch" field I request "Parent".
However, this only gives me to the immediate parent. If the parent has a parent, that does not seem to be returned. In contrast, if I request a story's children, I can go down many levels.
Is there a way with the WSAPI to do a single query of user stories so that I can get to the root parent of each? And in fact, sometimes the parent is a Feature level portfolio item, so ideally that needs to be included as well.
It is only possible to traverse one level of the hierarchy at a time in a WSAPI request. You'll have to continue loading each parent until you reach the top.
Check out this answer:
Lookback API: Find all leaf node stories under a known parent
Lookback API makes it possible to grab the entire hierarchy of parent/child objects with a single query. LBAPI is currently in a limited public preview for a subset of Rally subscriptions, but the goal is to make a full public preview available soon.
Related
So far I have only been able to reach the parent one step up, in this case the name of the feature.
You're right, in general hierarchy is limited to 2 levels in a single response. There are some shortcuts here and there though, depending what you need.
If you fetch both Feature and Parent I think that will give you the feature's parent info. You can't go any higher than that in one request though...
I am using this rally API to get the list of all the stories:
https://rally-n.rallydev.com/slm/webservice/v2.0/hierarchicalrequirement?query=(Project.Name="My_Parent_Project")&order=OrderString
My_Parent_Project actually do not have any user stories, but its children projects (my_child_1 and my_child_2) has user stories.
Is there any specific field, which I can mention to get all the user stories including child projects.
I can see Rally UI has option to get the data from Child project. So I believe there must be an option to get this data using above API. (They use projectScopeUp=false&setScopedDown=true which doesn't seems to be working with
"hierarchicalrequirement" API.
You're really close.
It seems like you've already found the project scoping docs:
https://rally1.rallydev.com/slm/doc/webservice/projectscope.jsp
I think if you just swap your (Project.Name = "My_Parent_Project") query to instead use the project=/project/12345 query string parameter and include projectScopeDown=true you should be all set.
Very fond of the release burn down chart, but as we have features from different areas in a single release I am looking to get a Burn Down Chart scoped to a specific top level story. In this case the only stories to be considered would be its leaf stories that are scheduled for the release in question.
Does anyone have an idea if this is possible or where to start? I found the code here: https://github.com/RallyApps/app-catalog/tree/master/src/apps/charts/burndown but couldn't see how to restrict the scope of the work products being considered.
Other ways I tried to get this view:
- I tried a custom view on the main user-stories view filtered to a release, but the summary rows give you a summary for all the stories in that tree, not just those which it filtered to
- Track work product status view only does story count whereas I need the total story points from the stories (not tasks) to be reported on
If anyone knows anywhere else I can get a nice view of a story hierarchy progress, scoped to a release that would also be helpful.
As a starting point, the app accesses historical data via Lookback API. Documentation for it is available here.
The example below is from "Work item hierarchy" section of that document:
To retrieve all Stories that descend from Story 333 (includes 333,
444, 555, 666, 888, and 999 but not Defect 777), you would include
this clause in your query:
{
_ItemHierarchy: 333,
_TypeHierarchy: “HierarchicalRequirement”
}
BurnDownChart.js from the repo has a store of type "Rally.data.lookback.SnapshotStore", which you may filter using work item hierarchy.
AppSDK2 SnapshotStore accesses data from Lookback API.
I want to query for user stories and the Initiative that each story falls under. My fetch property looks like:
...
model: 'UserStory',
fetch: ['Name', 'PortfolioItem', 'Parent'],
...
This fetches the PortfolioItem/Feature object, PortfolioItem/FeatureGroup object but not the PortfolioItem/Initiative. The FeatureGroup object does not show a 'Parent' property.
In short, how can I fetch the parent's parent without querying separately for Initiatives and comparing the '_ref' or something like that?
For server performance reasons the hierarchical relationships will only be populated for one level with each request. You'll have to make subsequent requests to build the remaining tiers.
If you hit the new Lookback API (unreleased when Kyle first answered, now in open preview), the snapshots returned include a field _ItemHierarchy which will include the ObjectID of all ancestors including all the way up through Portfolio Items.
You can find information on the LBAPI here. There is support for querying it in the App SDK 2.0's SnapshotStore. Note that SDK 2.0p6 (releasing soon) has some improvements.
Old, old question. But I recently did the same thing for the entire tree. I didn't use the lookback api. I created a model and stored the data and went through the parentage of each portfolio item.
Perhaps not the most efficient way, but it works.
I'm trying to aggregate some information about the kanban states of my user stories. If query a PifTeam item, I get a summarized collection of UserStories associated with it.
Example query:
https://rally1.rallydev.com/slm/webservice/1.40/portfolioitem/pifteam/99999999999.js
However I then have to run a loop on the UserStories collection, individually querying each one to get at the information I need. This potentially results in a lot of web service calls.
Is there a way to return the full hierarchical requirement information in the original pifteam query so that there is only one webservice call which returns all sub-objects? I read the webservice api and was trying to play with the fetch parameter but had no success.
This functionality will be disabled in WSAPI 2.0 but will continue to be available in the 1.x versions. That said, you should be able to use a fetch the fields on story that you need like this:
/pifteam/9999.js?fetch=UserStories,FormattedID,Name,PlanEstimate,KanbanState
Fetch will hydrate the fields specified on sub objects even if the root object type doesn't have those fields. So by fetching UserStories the returned collection will populated with stories, each having the FormattedID, Name, PlanEstimate and KanbanState fields included.
There is no way to do it from Rally's standard Web Services API (WSAPI) but you can from the new Lookback API (LBAPI). The query would look something like this:
https://rally1.rallydev.com/analytics/v2.0/service/rally/workspace/<ObjectID_for_Workspace>/artifact/snapshot/query.js?find={__At:"current",_TypeHierarchy:"HierarchicalRequirement",Children:null,_ItemHierarchy:<ObjectID_for_PortfolioItem>}&fields=["Name"]
Fill in the ObjectIDs for your Workspace and PortfolioItem. The _ItemHierarchy field will cross work item type boundaries and goes all the way from PortfolioItems down through the Story hierarchy down to Defects and even Tasks, so I added _TypeHierarchy:"HierarchicalRequirement" to limit it to Stories. I have specified Children:null which means you'll only get back leaf Stories. The __At:"current" clause get's the current tree and values. Remember, it's the "Lookback" API, so you can retrieve the state of the object at any moment in history. __At:"current" says to get the current values and tree.
Note, the LBAPI is delayed from current values in the system by anywhere from seconds to minutes. Typically it's about 30 seconds behind. You can see how far behind it is by checking the ETLDate field in the response.
Details about the LBAPI can be found here. Note, that the LBAPI is available in preview now for almost all Rally customers. There are still a number of customers where it is not yet turned on. The best way to tell if it's working for your subscription is to try the query.