I am looking for fields in task called is_completed and completed_on.
When I do the /projects/#PROJECT-ID#/tasks API call I see is_completed but I do not see completed_on.
We are using the Cloud based version of Active Collab 4.
Any reason why I am not seeing completed_on?
In Active Collab 4, there is a difference between "brief" API responses (used when returning large lists of objects), and detailed responses (used when a single object is returned via API).
When you are listing a list of tasks, you will get all individual tasks in brief format, but when you fetch details of each task, you'll get a detailed response.
In brief task responses, completed_on timestamp is not included, only whether tasks is completed or not (is_completed). To get the timestamp of completed tasks, make an additional call to task API for each task that is completed:
https://activecollab.com/help-classic/books/api/tasks#s-task-id
PS: In Active Collab 5, we removed brief and detailed concept, so each object always returns a single set of properties.
Related
I'm trying to get all Tasks from a Story with the DevOps API but I only found a relation expand command which is not that what I want.
So how can I "expand" a Story to see all Tasks?
API REQ: https://----/----/----/_apis/wit/workitems/ID?api-version=5.1
With that I only get like the name, desc, state, reason, assignedto and so on.
Check with the related REST API and Azure CLI, it seems that currently we have no easy way to get the list of Tasks that have been linked to a User Story.
You can execute the API "Work Items - Get Work Item" and get the list of work items that have linked to the specified User Story from the Response body of this API.
GET https://dev.azure.com/{organization}/{project}/_apis/wit/workitems/{id}?$expand={$expand}&api-version=6.1-preview.3
In the list you can get the URL of each linked work item. You can get the detailed information of each work item via sending request to the URL. From the detailed information, you can get the work item type of each item.
Is there anyway to find out how many webapi calls that are used against quota when doing rest API call (or soap api call) reading leads from a list? Please note that this is purely read-only, where we are getting data from a static list of leads, which are added using a smart campaign.
We are bringing in 40 attributes from the Marketo lead record total 1600 chars. Depending on need, we might need to stage anywhere from 200K to 1 million records into a static list. We are successfully extracting all that data, but we would like to find out how many API calls are being utilized.
Each authenticated request to an endpoint counts as a call. You can also the usage API to see your daily usage: http://developers.marketo.com/documentation/rest/get-daily-usage/
Given a Rally project Id, I want to be able to browse through all the stories and the defects in the project and for each story/defect get the following information
Story/Defect Name, Date blocked, Date unblocked, Blocked Reason
There doesn't seem to a webservice API to list the blockers (past and current) on a given story or defect. The only way I can think of retrieving the above information is to go through the Revision History of a story/defect and parse the revision description (BLOCKED REASON added [Random Reason], BLOCKED changed from [true] to [false]). Is there a better way to retrieve the blocker information on a story or a defect? Thanks.
The Rally webservice API I'm looking at:
https://rally1.rallydev.com/slm/doc/webservice/
Historic data is available via Lookback API. It is more efficient than parsing RevisionHistory object in WS API.
Each snapshot in Lookback API will have a _PreviousValues collection. For each snapshot, if a field has changed from the prior snapshot, then the _PreviousValues collection will be hydrated for that value.
You may try a query where:
'_PreviousValues.Blocked' : {$exists: true}
I've noticed when retrieving a story/defect after first updating it, sometimes the retrieve response returns the field values as if the update never happened. Retrying the retrieve after a short delay (~500ms) returns the updated field values as expected. Is this a known behaviour? Is there any way of avoiding this?
I'm using the Rally API 2.0 - https://rally1.rallydev.com/slm/webservice/v2.0/
The update is being performed using this URI:
POST /slm/webservice/v2.0/Defect/14173461229?key=<key> HTTP/1.1
I'm retrieving the story after update as follows:
GET /slm/webservice/v2.0/artifact?query=(ObjectId%20=%2014173461229)&start=1&pagesize=20&fetch=true HTTP/1.1
What is your integration doing that it needs to re-poll the artifact within < 1 second of POST'ing an update? Is there a second process that does polling that is revealing the latency for the updates? Does your integration run multiple threads? Does the response time vary at all depending on time of day, etc.? There are any number of factors that could be at play here, but 500 ms doesn't seem like an un-reasonable refresh rate given factors such as latency over HTTP/S as well as server-side database and cache updates. That said, for an in-depth look you may wish to inquire with Rally Support (rallysupport#rallydev.com) as they have tools that can help evaluate server-side response time corresponding to requests by specific UserID.
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.