[API version 3.2, Timetracker extension version 5.48.1.58602, online ADO organization]
Hello there,
We have added a custom field to feature work items, let's say it's reference name is "Custom.Year". I am now trying to get the TrackedTotal time of every Feature where "Custom.Year" is not equal to null.
I was using the workItemsHierarchy endpoint, but since it does not return work items that have a parent (and some of the Features have an Epic as their parent) I decided to switch to using workItemsHierarchyAllLevels. My issue here is that I am no longer able to filter by my custom field. Here's what my current query looks like:
https://<org>.timehub.7pace.com/api/odata/v3.2/workItemsHierarchyAllLevels?$select=CustomStringField1&customFields=Custom.Year&workItemsFilter=CustomStringField1 ne null
But this returns an error with status code 500 and this message:
Is this intended/known or am I not using the query properly? For reference if instead I use something like this:
https://<org>.timehub.7pace.com/api/odata/v3.2/workItemsHierarchyAllLevels?$select=CustomStringField1&customFields=Custom.Year&workItemsFilter=System_Id eq 12345
Then I get a response where my custom field has the value intended:
Thanks
-
Hello Vincent,
Thank you for reaching out to us.
Please try to use $filter to filter out work items without a custom field, like this:&$filter=CustomStringField1 ne null
And since the workItemsHierarchyAllLevels endpoint requires a workItemsFilter, then please try to use a different one.
You can use it to specify a Project, in this way:&workItemsFilter=System_TeamProject eq 'Project1'
Best regards,
Vanja -
Hello Vanja,
Thanks for the answer, unfortunately my issue is that &workItemsFilter does not seem to work with custom fields. Is there a way to filter out results from workItemsHierarchyAllLevels with workItemsFilter using a custom field?
Here's what I am currently doing and thought would work, but doesn't:https://<org>.timehub.7pace.com/api/odata/v3.2/workItemsHierarchyAllLevels?$select=CustomStringField1&customFields=Custom.Year&workItemsFilter=CustomStringField1 ne null
Although I made sure to select the custom field and indicate to the API which field CustomStringField1 should correspond to. It instead returns this error:
"statusCode": 500,
"errorCode": "UnexpectedError",
"errorDescription": "Unexpected error occurred",
"fields": {
"originalMessage": "Could not find a property named 'CustomStringField1' on type 'Timetracker.Entities.Models.WorkItemCacheEntry'.",lCordially
-
Also, while we're at it. The workItemsHierarchyAllLevels endpoint does not seem to return a TrackedTotal value that takes into consideration the time inputted on it's children work items. Is there a way to do so?
TrackedTotal is always equal to TrackedItself even though I have Product Backlog Items as children of my Feature, and these PBIs have time on them.
Thanks
-
Hello Vanja,
Ok interesting, that works indeed, thanks!
FYI for anyone else stumbling across this thread here's what my query ended up looking like, showing only the elements relevant to my initial question:
https://<org>.timehub.7pace.com/api/odata/v3.2/workItemsHierarchyAllLevels?$select=CustomStringField1&customFields=Custom.Year&$filter=CustomStringField1 ne null&workItemsFilter=System_Id gt 0
-
Hi Vincent,
Good to hear that it works.
However, one note about you using the workItemsFilter in this way "&workItemsFilter=System_Id gt 0" - this prefilter was designed to narrow down the returned results in order to avoid hiting API limits. In the way it is constructed here, you will still get all results for all work items. And the workItemsHierarchyAllLevels endpoint is the most heaviest on the API load, since it queries all work items with their entire hierarchy, if left unfiltered.
Could you please change the workItemsFilter to filter by type, or Project, or Area Path?
Best regards,
Vanja -
Hello Vanja,
Oh yes don't worry I just put the first filter that came to mind since I wanted to test $filter, it's not actually what I ended up using. I was only looking at the first page of results through Postman while investigating which API calls we should be using for our PowerBI report.
Thanks
Please sign in to leave a comment.
Comments
7 comments