It's all about the answers!

Ask a question

Query for WorkItems in a particular Dev. Line


Andy Berner (61127) | asked Jul 25 '08, 3:29 p.m.
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.

6 answers



permanent link
Christof Marti (681) | answered Jul 28 '08, 4:16 a.m.
You could use the following (using internal API):

WorkItemQueryModel model= WorkItemQueryModel.ROOT;
IItemQuery query= IItemQuery.FACTORY.newInstance(model);
query.filter(model.target().internalDevelopmentLine()._eq(query.newItemHandleArg()));
....

Christof
Jazz Work Item team

permanent link
Andy Berner (61127) | answered Jul 31 '08, 8:51 a.m.
Thanks...but is there no way to do it without internal api call?

permanent link
Christof Marti (681) | answered Aug 06 '08, 4:51 a.m.
No, currently not, please open an enhancement request if you need this.

Regards,

Christof
Jazz Work Item team


ajberner wrote:
Thanks...but is there no way to do it without internal api call?

permanent link
Patrick Streule (4.9k21) | answered Aug 08 '08, 4:16 a.m.
JAZZ DEVELOPER
No, currently not, please open an enhancement request if you need this.

I created a work item for this a while ago:

https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/32249

Regards,
Patrick
Jazz Work Item Team

permanent link
Pat McCarthy (12152) | answered Sep 05 '08, 9:58 a.m.
JAZZ DEVELOPER
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.

permanent link
John Doran (9182) | answered Nov 21 '09, 2:53 p.m.
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!

Your answer


Register or to post your answer.