Licensing issue when tryin to save work item in a job

I assume your code snipped is thought to run on the server.

Component code that runs on the server is called from a service. Each service request has a context. The context contains information about the requester of the service, i.e. the authenticated user. The context is remember as a thread locale.

By creating a new job your code looses the association with the context and thus the association with the authenticated users. Consequently you get a license problem reported.

There is no API conform way to copy and transfer the context to the newly created thread.

Kai

Hi,

I am trying to spawn a separate thread (making it as a Job) and calling the save work item in there.

Job job=new Job("Save Work Item")
{

@Override
protected IStatus run(IProgressMonitor arg0) {
.... childWorkingCopy.setState2(parentState);
// save the child
try {
workItemService.saveWorkItem2(childWorkingCopy, null, null);

} catch (TeamRepositoryException e) {...}

};
// job.setSystem(true);
//job.setUser(true);
// job.setPriority(Job.INTERACTIVE);

job.schedule();





But this code throws an error on the console:


Name: Save Work Item
ID: com.ibm.team.workitem.operation.workItemSave
Severity: ERROR
Summary: Missing required license
Description: The client access licenses assigned to the current user do not allow the "Save Work Item" operation. Assign one of the following license types to this user to allow this operation: Contributor, ClearCase Connector, Developer, Build System, ClearQuest Connector.
Severity: ERROR


This happens when we try to do a separate job for any operations built in RTC like Save work item operation here.

Please help with this error.

So what's the right way to do a follow-up action that's a long running operation?

I guess I should have asked it better this way: What's the right way to do a follow up action that's a long running operation, that updates other work items.

Follow-up actions should not be designed to be long running since they directly impact the success of the operation they are configured for. If a follow-up action fails, the transaction associated with the original operation is rolled back.

Long running operations are best implemented as event handlers. In your case it would be an event handler for work item change events.

Kai