Query for WorkItems in a particular Dev. Line
How can I query, using either the WorkItem Query API or the Repository Query API, for all work items that are associated with a particular development line?
To clarify the association I'm looking for, the TeamArea associated with a WorkItem is displayed in the RTC GUI, so I want all WorkItems whose team area is in the specific development line.
I know I could retrieve all the work items in the ProjectArea, then test each to see if it is "in" my development line (check the Category and the Target iteration, and then it's a somewhat complicated computation etc., but we can do it.) But I would want instead to filter for that in the Query and not get all the work items from other dev lines in the ProjectArea.
To clarify the association I'm looking for, the TeamArea associated with a WorkItem is displayed in the RTC GUI, so I want all WorkItems whose team area is in the specific development line.
I know I could retrieve all the work items in the ProjectArea, then test each to see if it is "in" my development line (check the Category and the Target iteration, and then it's a somewhat complicated computation etc., but we can do it.) But I would want instead to filter for that in the Query and not get all the work items from other dev lines in the ProjectArea.
6 answers
I'd worked this a bit and noticed that this thread was not updated with one of the alternatives we found.
The goal we had was finding work items for a given development line, or tree of iterations given a starting iteration tree.
My technique used the Work Item Query API and this key method from the process API:
Given the full iteration structure, which per the Javadoc makes further analysis easy:
So any iteration, or development line chosen as the root for finding all associated Work Items is available locally after that method call. This means that the itemManager always has the full item available without another server call and allow for an efficient determination of parent/child relationships.
Yes, the next step is a Work Item Query - two approaches were explored.
For all those Work Items in a single iteration:
For all Work Items associated to some tree of iterations given a root development line or iteration:
Where the implementation of getExpressionsForIteration(pa, iteration) includes this logic - the doGetExpressionsForIteration method explores the tree:
Net is a big OR in the query, yes, as big as the iteration tree root and all its children; this is exactly what you get if you build the query with the work item UI.
Only the work items of interest are returned when the query is executed.
Net is two round trips from the program to the RTC Team Server. Only the work item data of interest is returned.
How I did it at least.... comments welcome.
The goal we had was finding work items for a given development line, or tree of iterations given a starting iteration tree.
My technique used the Work Item Query API and this key method from the process API:
private static List<IItemHandle> iterStruct = null;
iterStruct = processClientLibrary.fetchCompleteIterationStructure(projectArea, new NullProgressMonitor());
Given the full iteration structure, which per the Javadoc makes further analysis easy:
Fetches the complete iteration structure of the given project area. Returns an unsorted list containing the project area, its iteration types, its development lines and its iterations. All returned development lines and iterations are shared in the item manager.
The returned iterations are managed by the item manager.
So any iteration, or development line chosen as the root for finding all associated Work Items is available locally after that method call. This means that the itemManager always has the full item available without another server call and allow for an efficient determination of parent/child relationships.
Yes, the next step is a Work Item Query - two approaches were explored.
For all those Work Items in a single iteration:
// Create an expression for a given project area
Expression paExpr = getExpressionForProjectArea(pa);
// Create an expression for a given iteration
Expression targetExpr = getExpressionForIteration(pa, iteration);
// Combine the above to make a complex expression
Term combined= new Term(Term.AND, new Expression[] { targetExpr, paExpr});
// Run query and print out some summary details
IQueryResult<IResolvedResult<IWorkItem>> wis = findWorkItems(combined);
For all Work Items associated to some tree of iterations given a root development line or iteration:
// Create an expression for a given project area
Expression paExpr = getExpressionForProjectArea(pa);
// Create an expression for an iteration tree
Term targetExp = new Term(Term.OR, getExpressionsForIteration(pa, iteration));
// Combine the above to make a complex expression
Term combined = new Term(Term.AND, new Expression[] {paExpr, targetExp});
// Run query and print out some summary details
IQueryResult<IResolvedResult<IWorkItem>> wis = findWorkItems(combined);
Where the implementation of getExpressionsForIteration(pa, iteration) includes this logic - the doGetExpressionsForIteration method explores the tree:
private ArrayList<Expression> doGetExpressionsForIteration(IProjectArea pa, IIteration iteration) throws TeamRepositoryException {
ArrayList<Expression> expressions = new ArrayList<Expression>();
// add an expression for the current iteration
expressions.add(getExpressionForIteration(pa, iteration));
IIterationHandle[] ihChildren = iteration.getChildren();
for (int j = 0; j < ihChildren.length; j++) {
IIterationHandle ihc = ihChildren[j];
// Iteration child not an item - need to get the item from the item manager
IIteration ic = getIterationForHandle(ihc);
// get expressions for the iteration and its children
expressions.addAll(doGetExpressionsForIteration(pa, ic));
}
return expressions;
}
Net is a big OR in the query, yes, as big as the iteration tree root and all its children; this is exactly what you get if you build the query with the work item UI.
Only the work items of interest are returned when the query is executed.
Net is two round trips from the program to the RTC Team Server. Only the work item data of interest is returned.
How I did it at least.... comments welcome.
I'd worked this a bit and noticed that this thread was not updated with one of the alternatives we found.
The goal we had was finding work items for a given development line, or tree of iterations given a starting iteration tree.
My technique used the Work Item Query API and this key method from the process API:private static List<IItemHandle> iterStruct = null;
iterStruct = processClientLibrary.fetchCompleteIterationStructure(projectArea, new NullProgressMonitor());
Given the full iteration structure, which per the Javadoc makes further analysis easy:
Fetches the complete iteration structure of the given project area. Returns an unsorted list containing the project area, its iteration types, its development lines and its iterations. All returned development lines and iterations are shared in the item manager.
The returned iterations are managed by the item manager.
So any iteration, or development line chosen as the root for finding all associated Work Items is available locally after that method call. This means that the itemManager always has the full item available without another server call and allow for an efficient determination of parent/child relationships.
Yes, the next step is a Work Item Query - two approaches were explored.
For all those Work Items in a single iteration:
// Create an expression for a given project area
Expression paExpr = getExpressionForProjectArea(pa);
// Create an expression for a given iteration
Expression targetExpr = getExpressionForIteration(pa, iteration);
// Combine the above to make a complex expression
Term combined= new Term(Term.AND, new Expression[] { targetExpr, paExpr});
// Run query and print out some summary details
IQueryResult<IResolvedResult<IWorkItem>> wis = findWorkItems(combined);
For all Work Items associated to some tree of iterations given a root development line or iteration:
// Create an expression for a given project area
Expression paExpr = getExpressionForProjectArea(pa);
// Create an expression for an iteration tree
Term targetExp = new Term(Term.OR, getExpressionsForIteration(pa, iteration));
// Combine the above to make a complex expression
Term combined = new Term(Term.AND, new Expression[] {paExpr, targetExp});
// Run query and print out some summary details
IQueryResult<IResolvedResult<IWorkItem>> wis = findWorkItems(combined);
Where the implementation of getExpressionsForIteration(pa, iteration) includes this logic - the doGetExpressionsForIteration method explores the tree:
private ArrayList<Expression> doGetExpressionsForIteration(IProjectArea pa, IIteration iteration) throws TeamRepositoryException {
ArrayList<Expression> expressions = new ArrayList<Expression>();
// add an expression for the current iteration
expressions.add(getExpressionForIteration(pa, iteration));
IIterationHandle[] ihChildren = iteration.getChildren();
for (int j = 0; j < ihChildren.length; j++) {
IIterationHandle ihc = ihChildren[j];
// Iteration child not an item - need to get the item from the item manager
IIteration ic = getIterationForHandle(ihc);
// get expressions for the iteration and its children
expressions.addAll(doGetExpressionsForIteration(pa, ic));
}
return expressions;
}
Net is a big OR in the query, yes, as big as the iteration tree root and all its children; this is exactly what you get if you build the query with the work item UI.
Only the work items of interest are returned when the query is executed.
Net is two round trips from the program to the RTC Team Server. Only the work item data of interest is returned.
How I did it at least.... comments welcome.
Thank you, this is very cool!