We have added our own attributes in a work item and would like to
produce queries on such attributes. How can this be done? Besides we
also tried to use this fields in the 'required properites' without
any sucess. Are these scenarios applicable?

In the UI: The custom attributes show up in the Query Editor like the
built-in attributes.

Using Work Item Query API:

IQueryableAttributeFactory factory=
QueryableAttributes.getFactory(IWorkItem.ITEM_TYPE);
IQueryableAttribute attribute= factory.findAttribute(projectArea,
customAttributeIdentifier, auditableClient, monitor);

AttributeExpression expression= new AttributeExpression(attribute,
operator, value);
IQueryResult<IResolvedResult<IWorkItem>> result=
queryClient.getResolvedExpressionResults(projectArea, expression,
IWorkItem.SMALL_PROFILE);
while (result.hasNext(monitor)) {
IWorkItem workItem= result.next(monitor).getItem();
...
}


Using Repository Query API:

IItemQuery query= IItemQuery.FACTORY.newInstance(WorkItemQueryModel.ROOT);
IPredicate keyPredicate=
WorkItemQueryModel.ROOT.stringExtensions().key()._eq(query.newStringArg());
IPredicate valuePredicate=
WorkItemQueryModel.ROOT.stringExtensions().value()._like(query.newStringArg(),
ESCAPE_CHARACTER);
query.filter(keyPredicate._and(valuePredicate));
IItemQueryPage page= queryService.queryItems(query, parameters, pageSize);

HTH,
Patrick
Jazz Work Item Team

i noticed that if the type of the attribute is an enumeration, the
fields are shown in the UI. SO thanks, that is settled.

All of them should be shown in the Query Editor UI, not only the
enumerations (with the exception of booleans in the Web UI).

On the other hand what about the 'required properites'? is there a way
to make the added fields obligatory? Do i need to change the API?

You should be able to add the attribute to the list of required
properties in the process specification:

<precondition xmlns="http://com.ibm.team.workitem/requiredProperties"
id="com.ibm.team.workitem.advisor.requiredProperties" name="Required
Properties">
<properties workItemTypeCategory="com.ibm.team.workitem.workItemType">
<property id="your.custom.property"/>
</properties>
</precondition>

Regards,
Patrick

Hello. I followed along with the basic question and response, but have some follow-up questions about the response and the rules of engagement with work items, queries, and other related objects as we integrate with the Jazz platform.

I'm considering the code samples posted here as valid for M5, but not Beta2. The Beta2 code I have to query a work item is very different from the code I needed to do the same in M5.

Beta2:
private IQueryResult findWIContainsSummaryText(String summary) throws TeamRepositoryException {

IQueryClient queryClient = (IQueryClient) getTestRepo().getClientLibrary(IQueryClient.class);
IAuditableClient auditableClient = (IAuditableClient) getTestRepo().getClientLibrary(IAuditableClient.class);

IQueryableAttribute summaryAttribute = QueryableAttributes .getFactory(IWorkItem.ITEM_TYPE).findAttribute(getProjectArea(), IWorkItem.SUMMARY_PROPERTY, auditableClient, null);
Expression expression= new AttributeExpression(summaryAttribute, AttributeOperation.CONTAINS, summary);
IQueryResult result= queryClient.findAll(expression, IWorkItem.LARGE_PROFILE, null);
return result;
}

In M5 part of the above code looks like this:
IQueryResult<IResolvedResult<IWorkItem>> result = queryClient.getResolvedExpressionResults(getProjectArea(), expression, IWorkItem.SMALL_PROFILE);

And IQueryResult no longer extends Iterable - changing other code I have that processes the query result.

Q1 - why the change to IQueryResult? Beyond being different, using the JDT code assist on an IQueryResult that extends Iterable is a straightforward (IQueryResult.iterable()), but in M5 that approach must change as the IQueryResult object has changed and does not fit in the code suggested by code assist as well as before.

What I saw in Beta2 vs what I ended up with in M5:

// XXX Was/Is (Beta2/M5)
// for (Iterator iterator = result.iterator(); iterator.hasNext();) {
for (result.getTotalSize(null); result.hasNext(null);) {

--

The sample provided for the "repository query API" includes a reference to WorkItemQueryModel, which is in a package marked as internal.

Q2 - are you saying I'm allowed to use internal packages/classes to build queries on the repository?

I find that odd given our "training" with regards to Eclipse and what is available as an API. Using the same rules/patterns would seem to be appropriate, but I'd also like to be able to look at the repository query approach. Can that approach be used without any .internal. package refs?

Regards,

Pat Mc.

Q1 - why the change to IQueryResult? Beyond being different, using
the JDT code assist on an IQueryResult that extends Iterable is a
straightforward (IQueryResult.iterable()), but in M5 that approach
must change as the IQueryResult object has changed and does not fit
in the code suggested by code assist as well as before.

What I saw in Beta2 vs what I ended up with in M5:

// XXX Was/Is (Beta2/M5)
// for (Iterator iterator = result.iterator(); iterator.hasNext();) {
for (result.getTotalSize(null); result.hasNext(null);) {

The API change became necessary in conjunction with support for link
queries and for performance considerations. The new API allows to query
for handles or resolved items while the old one always returned resolved
items. In addition, pagination was not transparent in the old API and
there was no way to limit the result size.

We try to keep the APIs as stable as possible, and I am sorry that this
change is breaking your code. Keep in mind however, that we are
publishing Betas and going from one milestone to the next can require
adoption/migration.

The sample provided for the "repository query API" includes
a reference to WorkItemQueryModel, which is in a package marked as
internal.

Q2 - are you saying I'm allowed to use internal packages/classes to
build queries on the repository?

I overlooked the fact that WorkItemQueryModel is internal, and we are
probably not going to make it API at this stage.

I find that odd given our "training" with regards to Eclipse
and what is available as an API. Using the same rules/patterns would
seem to be appropriate, but I'd also like to be able to look at the
repository query approach. Can that approach be used without any
internal. package refs?

We are using the same rules/patterns, but typically start off with
internal implementations until the need for API arises. As I mentioned
above, the APIs are also not cast in stone yet while we are still in the
development phase for 1.0.

Regards,
Patrick
Jazz Work Item Team

When I try to build the following attribute I get an IllegalArgumentException
IQueryableAttribute queryableCustom = QueryableAttributes.getFactory(IWorkItem.ITEM_TYPE)
.findAttribute(projectArea, "modified", auditableClient, null);
AttributeExpression attrExpr = new AttributeExpression(queryableCustom,AttributeOperation.GREATER_OR_EQUALS, new Timestamp(2010, 10, 04, 00, 00, 00, 00));



Exception trace is as follows


Caused by: java.lang.IllegalArgumentException
at com.ibm.team.process.internal.common.util.AbstractProcess.computeConfigurationData(AbstractProcess.java:328)
at com.ibm.team.process.internal.common.util.AbstractProcess.getProjectConfigurationData(AbstractProcess.java:313)
at com.ibm.team.process.internal.common.util.AbstractProcess.getProjectConfigurationData(AbstractProcess.java:299)
at com.ibm.team.workitem.client.internal.AuditableClientProcess.findProcessConfiguration(AuditableClientProcess.java:68)
at com.ibm.team.workitem.common.internal.EnumerationManager$InternalEnumerations.resolve(EnumerationManager.java:52)
at com.ibm.team.workitem.common.internal.EnumerationManager.updateCache(EnumerationManager.java:198)
at com.ibm.team.workitem.common.internal.util.CacheHelper.internalCheckCache(CacheHelper.java:117)
at com.ibm.team.workitem.common.internal.util.CacheHelper.checkCache(CacheHelper.java:74)
at com.ibm.team.workitem.common.internal.util.CacheHelper.checkCache(CacheHelper.java:65)
at com.ibm.team.workitem.common.internal.EnumerationManager.internalResolve(EnumerationManager.java:173)
at com.ibm.team.workitem.common.internal.EnumerationManager.resolve(EnumerationManager.java:169)
at com.ibm.team.workitem.common.internal.WorkItemCommon.resolveEnumeration(WorkItemCommon.java:453)
at com.ibm.team.workitem.common.internal.model.EnumerationAttributeType.getNullValue(EnumerationAttributeType.java:41)
at com.ibm.team.workitem.common.internal.model.impl.AttributeImpl.getNullValue(AttributeImpl.java:875)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.ibm.team.repository.common.internal.util.ItemStore$ItemInvocationHandler.invoke(ItemStore.java:597)
at $Proxy17.getNullValue(Unknown Source)
at com.ibm.team.workitem.common.internal.expression.WorkItemQueryAttributeFactory.getNullValue(WorkItemQueryAttributeFactory.java:274)
at com.ibm.team.workitem.common.internal.expression.WorkItemQueryAttributeFactory.findNonLinkAttributes(WorkItemQueryAttributeFactory.java:238)
at com.ibm.team.workitem.common.internal.expression.WorkItemQueryAttributeFactory.updateCache(WorkItemQueryAttributeFactory.java:172)
at com.ibm.team.workitem.common.internal.util.CacheHelper.internalCheckCache(CacheHelper.java:117)
at com.ibm.team.workitem.common.internal.util.CacheHelper.checkCache(CacheHelper.java:74)
at com.ibm.team.workitem.common.internal.expression.WorkItemQueryAttributeFactory.findAttribute(WorkItemQueryAttributeFactory.java:137)
at com.opshub.rtc.poller.RTCPoller.queryForWI(RTCPoller.java:257)
at com.opshub.rtc.poller.RTCPoller.generateEvents(RTCPoller.java:102)
... 1 more