Using the Rally Rest Api I'm trying to get a User Story at a given point in time, like I request the User Story now.
I know how to get the Hierarchical Requirement
https://rally1.rallydev.com/slm/webservice/v2.0/HierarchicalRequirement/‹ObjectID›/
I know how to get the revisions
https://rally1.rallydev.com/slm/webservice/v2.0/RevisionHistory/‹ObjectID›
Now with this, I have all the history of revisions (Created [rev 0], Name changed [rev 1], etc [rev ..], BLOCKED [rev N -1], UNBLOCKED [rev N])
Let's say I want to see the FULL Hierarchical Requirement at rev 2 (with the new name) or the FULL Hierarchical Requirement at rev N-1, when it was blocked, but I want to get it like if I was doing
https://rally1.rallydev.com/slm/webservice/v2.0/HierarchicalRequirement/‹ObjectID›/
Is there a way to get these snapshots?
If you want to see what a particular user story looked like at a specific point in time, you would use the lookback api.
Within the find parameter you will specify at least 2 options:
ObjectID: The ID of the artifact you're interested in
__At: This is an ETL Date Timestamp specifying the point in time that the snapshot will represent. For this, you can use the CreationDate field that is found on each of the Revision objects from your previous query.
An example request looks like this:
https://rally1.rallydev.com/analytics/v2.0/service/rally/workspace/123456789/artifact/snapshot/query.js?find={ObjectID:123456789,__At:"2020-12-10T00:00:00Z"}&fields=true
Now what I can't be certain of without testing is whether or not using the Revision CreationDate in the Lookback query will return the state of the artifact just before the change or just after. This is because the creation of Revisions in the WSAPI and the creation of snapshots in the LBAPI aren't coupled that tightly (from what I understand). You'll have to do some testing to verify and maybe adjust the timestamp accordingly.
Related
Let's say I have a pull request with three commits, commit-a, commit-b and commit-c.
For every commit, I would like to obtain the aggregate diff within the pull request. That is, when I'm using the GitHub API to request the diff for commit-b I would like to get the changes made in commit-b combined with the changes in commit-a.
One way to do that would be to compare each commit to the state of the pull request before the pull request was opened. That is, compare to the parent-commit of commit-a.
Using the compare commits API, for e.g. commit-b that would be: <base_url>/compare/parent-commit...commit-b.
However, in principle commit-a can have any number of parent commits, and I do not know how to distinguish between them and which was one to use as a reference point.
Hope my question is clear, otherwise I'm happy to provide more details. Thanks!
I am attempting to retrieve all work items currently or previously associated with a given Iteration from Azure DevOps, either through an in-system query or through the API. I need this information to calculate sprint predictability metrics.
As far as I can tell, ADO only stores the latest Iteration in the work items fields, so the API call to ask for tickets associated with a Past iteration does not include any tickets that may have been moved to a different iteration mid-sprint. Likewise, they query options do not allow for something like a "was" operator to test for work items with may have met the criteria in the past.
Short of pulling each work item history individually through the API and creating my own iteration timeline for all tickets in the system, how can I get this information?
Take a look at this. You have to use the "was ever" operator in the iteration path. To do so, you have to query for it using the WIQL-Syntax.
So you'll have to add
...
AND (
EVER (
[System.IterationPath] = #currentIteration('[YourTeam]\... <id:...>'))
to the WHERE part of the query.
If you want to see an extended example, look here
I need to pull out a report of the actuals that is being entered by each person in my team date-wise in the time span which I am allowed to specify. Its basically not for any accounting purposes but just to monitor the effort entered by each user on a day.
The closest thing I have found based on my preliminary search is the Weekly Actuals custom report(https://help.rallydev.com/weekly-actuals-report).
But it doesn't show the date-wise information. Is there any app already developed for my requirement or should I need to tweak the weekly actuals report?
Note: Not interested to install the time-tracker module since most of the users in my organization are used to tracking effort through actuals.
Rally LookbackAPI will give you historic data. You may write an app using shapshot store intended to retrieve data from the Lookback API.
Here is a LookbackAPI endpoint that returns snapshots where Actuals were updated:
https://rally1.rallydev.com/analytics/v2.0/service/rally/workspace/111/artifact/snapshot/query.js?find={"Project":222,"_TypeHierarchy":"Task","_PreviousValues.Actuals":{$exists: true},_ValidFrom:{$gte: "2014-05-01T00:00:00.000Z",$lt: "2014-05-13T00:00:00.000Z"}}&fields=["_UnformattedID","Actuals","_PreviousValues.Actuals","_ValidFrom","_ValidTo"]
and an example of the returned result:
Results: [
{
_ValidFrom: "2014-05-12T17:08:27.598Z",
_ValidTo: "9999-01-01T00:00:00.000Z",
_UnformattedID: 157,
Actuals: 4,
_PreviousValues: {
Actuals: 0
}
}
]
where _ValidFrom: "2014-05-12T17:08:27.598Z" indicates the time when the snapshot was created - the Actuals was updated. Since this was the last change to Actuals on this task TA157, the _ValidTo is set to infinity. The result shows both the updated value (4) and previous value (0) of Actuals.
To try this endpoint make sure to change 111 and 222 with valid ObjectIDs of your workspace and project respectively.
There is a similar question about ToDo answered in this post.
It is possible to get some historic data by parsing revision history via Web Services API and looking for CreationDate on a revision where Actuals update was recorded. See 'side note' in this post. But this is expensive and inefficient.
Weekly Actuals is a legacy app based on AppSDK1. AppSDK1 cannot access LookbackAPI.
Is it possible to do object counts on the server side of Rally with the WSAPI?
For example, I've got an app that would like to count the number of unresolved defects for each project in our workspace. I don't need to know anything about those defects themselves, so I just want a count, and don't need any other data pulled back.
Any way to do this?
You might want to check out Alan's helpful answer to this Question:
Rally: Pull stories counts by schedule state for a release?
The analog for Defects would be:
https://rally1.rallydev.com/slm/webservice/1.31/defect.js?query=(State < "Fixed")
It does pull all the data, but you can grab the TotalResultCount attribute that is returned in the response to get the number of Defects matching your query.
The are some articles are written in several parts,
for example, I got those articles from IBM developer works:
Distributed data processing with
Hadoop, Part 1:Getting started
Distributed data processing with
Hadoop, Part 2:Going further
Distributed data processing with
Hadoop, Part 3: Application
development
I will index those three articles separately. And some one search certain keywords, it is possible the part3 is on the top of hit whle part1 is on the 32th. Therefor, if I list results page by page, the part1 and part3 will display on different page.
How can I make sure the hitted documents in the same series displayed together?
I guess in SQL, we can use "group by".
I believe what you are asking for is Field Collapsing, which is currently a trunk feature in Solr, and will be incorporated into the next Solr version.
If you want to roll your own, One possible way to do this is:
Add a "series id" field to each document that is a member of a series. You will have to ensure that this gets incremented for every new series.
Make an initial query to Lucene, and get a hit list.
For each hit, check to see if it has a series id; If it does, make another query by the series id in order to retrieve all the members of the series.
An alternative is to store the ids of all the series members in a field inside each member's document.