I want to get the list of items in the view lookup..but i just cant find what to query for that..i have tries everything but i just dont seem to get how to do it
I have even tried using
https://rally1.rallydev.com/slm/webservice/1.29/subscription.js?fetch=Workspaces,Projects,Name&pretty=true
but that only fetches me the worspace and projects
I am not sure what you mean by view lookup. In any case, it is not possible to query on all work items in a subscription. Here is an example of a query on all defects in a workspace, when Name,FormattedID,State are being fetched:
https://rally1.rallydev.com/slm/webservice/v2.0/defect?workspace=https://rally1.rallydev.com/slm/webservice/v2.0/workspace/1111&fetch=Name,FormattedID,State
All queries on work items are workspace scoped. You do not have to provide workspace explicitly as in the example above. If you are currently logged in to Rally in another tab of the same browser the context is already set, and this endpoint will work too:
https://rally1.rallydev.com/slm/webservice/v2.0/defect?&fetch=Name,FormattedID,State
You may want to narrow a scope by using a query parameter, e.g.
https://rally1.rallydev.com/slm/webservice/v2.0/defect?&query=(State = Open)&fetch=Name,FormattedID
Also, v2.0 removed the ability to return child collections in the same response for performance reasons. Now fetching a collection will return an object with the count and the url from which to get the collection data:
https://rally1.rallydev.com/slm/webservice/v2.0/Subscription/7777/Workspaces
where 7777 is OID of the subscription.
If you want to replicate a query in a custom view in Rally UI, open the view to determine the conditions and then build a similar query. Here is an example of a query that imitates a custom view below:
https://rally1.rallydev.com/slm/webservice/v2.0/hierarchicalrequirement?query=((Blocked = true) AND (Owner.UserName = nick01#test.com))
Related
I'm using the API call Items: Filter items by view
POST /item/app/{app_id}/filter/{view_id}/
The issue I'm having is that Podio is returning many fields specifically excluded from the view.
The app has many calculation fields which contain a lot of data.
I've defined a view to only return the fields I'm interested in, and in the UI in table view, it shows correctly (only 2 fields are included in the view).
But when fetching the view data via API, I get all the calculation fields in the app items that I'm not interested in.
Is this a bug or "expected" behaviour?
This is expected behavior. You can only partially control list of fields returned by filter-items-by-view call.
Please review similar question answered here: Podio Php - limit the amount of item fields returned
I'm using the WorkFront / AtTask API and when looking up Tasks, I'd like to filter them down to the Projects that contain specific Roles.
using /TASK/search/?fields=project:roles it will show me the Roles, but then I'm not sure how to filter on those.
Accessing a tertiary object directly (fails)
I tried /TASK/search/?project:roles:ID=aaaaaaa but the API returns (422) Unprocessable Entity.
Access from the parent object (works)
task -> project -> /PROJ/search/?roles:ID=aaaaaaa works, but involves sub-queries to the API that are costly and slow.
Access from secondary object's ID fields (works)
/TASK/search/?project:ownerID=bbbbbbb since it references a field of a secondary object and not yet another object. But I've only been able to make this work with single-instance references and don't know how to access the ID fields of collections without referencing them as objects.
So how could I filter or access down to a secondary object's collection? I can view them in a single API query, but can't seem to filter.
Task > It's Project > filter by Role
This functionality is not available in Workfront, neither through the API nor through built-in tools like Reports. This is due to a constraint on the database side of things. After seeing this question I spoke with my enterprise support team at Workfront and received confirmation of this from the DBAs.
The solution that you provided is the best you can do - split this query into the front and back half of your parameters and filter results within your code.
The best solution I can think of thus far is:
Pull the list of acceptable projects based on role.
/PROJ/search/?roles:ID=aaaaaa&...
Save the list of projects in memory
Pull the list of Tasks in question
/TASK/search/?...
Remove the tasks that don't have a project ID from step 2
This way it's only 2 queries and the project query should have a minimal impact in terms of size and number of entries.
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.
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.