The deprecation comment says:
"The correct way is to set the workflow action on save"

which means: the correct way to modify the state of a Work Item is to
execute a Workflow action on Work Item save. E.g. if you have a Work
Item working copy in hand, you call setWorkflowAction(String action) on
the working copy and then save it.

The reason for this is twofold:
- workflow actions are permission controlled by process. Setting work
flow states directly would circumvent process permissions.
- the workflow defines possible state transitions. Setting the state
directly, could result in "impossible" state transitions.

--Andre Weinand
RTC Work Item Team


On 2009-06-30 11:23:05 +0200,
jagermeister81@gmail-dot-com.no-spam.invalid (cargne80) said:

I'm extending RTC and I need to modify the workflow.

I found the method IWorkItem#setState2(Identifier<IState
value): void
but it's deprecated.

Is there a similar method?

Thanks in advance.

In your snippet please replace the line:
String openAction = actionReopen.toString();
with this:
String openAction = actionReopen.getStringIdentifier();

The String returned by toString() is not the ID expected by setWorkflowAction.

In a addition a disconnect() is missing too.

To your question:

In the rich (Eclipse) client modifying a Work Item through a
WorkItemWorkingCopy is recommended because that will automatically take
care of the issue that you get into if the work item is already open in
an editor (and has been already modified). The WorkItemWorkingCopy is a
shared buffer for the work item. If one client modifies the buffer,
other clients are notified (and can update their UI).

BTW, if you do not want to deal with all the possible cases of Work
Item modification in the rich client, please use the WorkItemOperation.
You can find information about it here:
https://jazz.net:443/wiki/bin/view/Main/ProgrammaticWorkItemCreation

Cheers,
--andre weinand
RTC Work Item Team



On 2009-06-30 14:38:03 +0200,
jagermeister81@gmail-dot-com.no-spam.invalid (cargne80) said:

OK, I understand the reason because setState2 is deprecated.

So, for example, if I want to set the workflow of my workitem 22989 to
ReOpen I need to write this code, right?

IWorkItem workItem =
service.findWorkItemById(22989, IWorkItem.FULL_PROFILE,
null);
IWorkflowInfo workflowInfo =
workItemCommon.findWorkflowInfo(workItem, monitor);

Identifier<IWorkflowAction> actionReopen =
workflowInfo.getReopenActionId();
String openAction = actionReopen.toString();

IWorkItemWorkingCopyManager workingCopyManager =
service.getWorkItemWorkingCopyManager();
IWorkItemHandle handle = service.findWorkItemById(22989,
IWorkItem.FULL_PROFILE, null);
workingCopyManager.connect(handle,
IWorkItem.FULL_PROFILE, null);
WorkItemWorkingCopy workingCopy =
workingCopyManager.getWorkingCopy(handle);
workingCopy.setWorkflowAction(openAction);
workingCopy.save(null);

Only a question: why do I need to use an istance of type
WorkItemWorkingCopy instead of using directly an IWorkItem istance?
I see that I can't modify directly an IWorkItem object.

Thanks Andre.

hi guys,

how about if i want to custom it on the server side ?
how can i get the workflow action and the workitem working copy ?

thanks

 Hi, I understand the use of Workflow Action to change the WorkItem state, bu suppose that I want to duplicate a WorkItem, creating a new one and move not resolved children to the new workItem, close the original and set the target to the new state directly, all of this in a propagation. Is there a way to do that not using the workflow action and create the workitem in the correct state without doing n consecutive saves()