It's all about the answers!

Ask a question

WorkItemWorkingCopy Save problem in RTC 2.0


Moti Wertheimer (18913627) | asked Aug 18 '09, 5:55 a.m.
JAZZ DEVELOPER
I had a script which updates workitems. It worked fine in RTC 1.0.1.
After upgrading to RTC 2.0 and rebuilding against 2.0 libraries, In some cases the save fails.
I don't get any exception during the script running and it seems that the save succeeded, but looking at the WI in RTC later shows no modification.

Here is my code:

// get work item copy
IWorkItemHandle handle = (IWorkItemHandle) workItem.getItemHandle();
IWorkItemWorkingCopyManager wcm = workitemClient
.getWorkItemWorkingCopyManager();
wcm.connect(handle, IWorkItem.FULL_PROFILE, monitor);
WorkItemWorkingCopy wc;

wc = wcm.getWorkingCopy(handle);
IWorkItem copiedWorkItem = wc.getWorkItem();
// end get work item copy

// change status
IAttribute stateAttribute = workitemClient.findAttribute(
projectArea, IWorkItem.STATE_PROPERTY, null);

copiedWorkItem.setValue(stateAttribute, resolvedState
.getStringIdentifier());
// end change status
.
.
.

wc.save(monitor);

Thanks,
Moti

4 answers



permanent link
Patrick Streule (4.9k21) | answered Aug 18 '09, 7:10 a.m.
JAZZ DEVELOPER
I had a script which updates workitems. It worked fine in RTC 1.0.1.
After upgrading to RTC 2.0 and rebuilding against 2.0 libraries, In
some cases the save fails.
I don't get any exception during the script running and it seems that
the save succeeded, but looking at the WI in RTC later shows no
modification.

The state of a work item should not be modified directly, but always via a
workflow action.

The work item server code validates the state of the work item on save:
The target state must be a valid transition from the previous state. In
the cases where you don't see an update, you are most likely setting the
work item state to a value that cannot be reached from the previous state
according to the workflow configuration.

--
Regards,
Patrick
Jazz Work Item Team

permanent link
Moti Wertheimer (18913627) | answered Aug 19 '09, 9:35 a.m.
JAZZ DEVELOPER

The state of a work item should not be modified directly, but always via a
workflow action.

The work item server code validates the state of the work item on save:
The target state must be a valid transition from the previous state. In
the cases where you don't see an update, you are most likely setting the
work item state to a value that cannot be reached from the previous state
according to the workflow configuration.

--
Regards,
Patrick
Jazz Work Item Team


Thanks for the reply Patric,

I think this is not the case because my script is doing state transition which is allowed in the workflow (I can do the same in the UI).

Is there any other issue, or can I look at some point in the RTC source to debug it?

Thanks,
Moti

permanent link
Patrick Streule (4.9k21) | answered Aug 19 '09, 9:49 a.m.
JAZZ DEVELOPER
Is there any other issue, or can I look at some point in the RTC
source to debug it?

To debug the issue, you could set a breakpoint in handleNotifySave(...) of
/com.ibm.team.workitem.service/src/com/ibm/team/workitem/service/internal/save/WorkflowTrigger.java

There is a call to
com.ibm.team.workitem.common.internal.WorkflowUtil.validState(IWorkflowInfo,
IWorkItem, String)

I assume that this call returns 'false' in your case.

--
Regards,
Patrick
Jazz Work Item Team

permanent link
Moti Wertheimer (18913627) | answered Aug 23 '09, 6:40 a.m.
JAZZ DEVELOPER

To debug the issue, you could set a breakpoint in handleNotifySave(...) of
/com.ibm.team.workitem.service/src/com/ibm/team/workitem/service/internal/save/WorkflowTrigger.java

There is a call to
com.ibm.team.workitem.common.internal.WorkflowUtil.validState(IWorkflowInfo,
IWorkItem, String)

I assume that this call returns 'false' in your case.


Thanks you Patrick!

It was really the case.
(during the upgrade something was changing in the actions and states that I didn't notice)

Thanks,
Moti

Your answer


Register or to post your answer.