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

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?

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

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.

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!