Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Getting exception when trying to remove change set linked to work item

Hello,

Currently, I want to remove the change set links to work item programmatically.
I am using RTC 6.0.5.
Below is the snip code to remove link:
IFileSystemWorkItemManager fileSystemWorkItemManager =
              (IFileSystemWorkItemManager) this.teamRepository.getClientLibrary(IFileSystemWorkItemManager.class);
          fileSystemWorkItemManager.deleteLinks(Arrays.asList(reference.getLink()), new NullProgressMonitor());
But the below exception is thrown:

[2018-08-31 13:57:04,888] [ERROR] [common]: CRJAZ2675I A client action caused the server exception that is listed below. The identifier for the error is 36841f3b-35ef-4048-8d3a-3e52a73283c8.

com.ibm.team.repository.common.InternalRepositoryException: Links of this type may only be modified by the defining component.

      Link Type: com.ibm.team.filesystem.workitems.change_set

      Defining Component: com.ibm.team.filesystem.workitems

      Requesting Component: com.ibm.team.workitem

      at com.ibm.team.repository.common.internal.marshal.util.MarshallerUtil.decodeExceptions(MarshallerUtil.java:377)

      at com.ibm.team.repository.common.internal.marshal.util.MarshallerUtil.decodeExceptions(MarshallerUtil.java:347)

      at com.ibm.team.repository.common.internal.marshal.util.MarshallerUtil.decodeFault(MarshallerUtil.java:312)

      at com.ibm.team.repository.transport.client.RemoteTeamService.constructExceptionFromFault(RemoteTeamService.java:716)

      at com.ibm.team.repository.transport.client.RemoteTeamService.executeMethod(RemoteTeamService.java:559)

      at com.ibm.team.repository.transport.client.RemoteTeamService.invoke(RemoteTeamService.java:202)

      at com.ibm.team.repository.transport.client.ServiceInvocationHandler.invoke(ServiceInvocationHandler.java:43)

      at com.sun.proxy.$Proxy38.save(Unknown Source)

      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

      at java.lang.reflect.Method.invoke(Method.java:498)

      at com.ibm.team.repository.client.internal.ServiceInterfaceProxy.invokeServiceCall(ServiceInterfaceProxy.java:254)

      at com.ibm.team.repository.client.internal.ServiceInterfaceProxy.invoke(ServiceInterfaceProxy.java:110)

      at com.sun.proxy.$Proxy38.save(Unknown Source)

      at com.ibm.team.workitem.client.internal.WorkItemSaveTransport$1.run(WorkItemSaveTransport.java:33)

      at com.ibm.team.repository.client.internal.TeamRepository$3.run(TeamRepository.java:1355)

      at com.ibm.team.repository.common.transport.CancelableCaller.call(CancelableCaller.java:79)

      at com.ibm.team.repository.client.internal.TeamRepository.callCancelableService(TeamRepository.java:1350)

      at com.ibm.team.workitem.client.internal.WorkItemSaveTransport.call(WorkItemSaveTransport.java:30)

      at com.ibm.team.workitem.client.internal.WorkItemSaveRunnable.run(WorkItemSaveRunnable.java:37)

      at com.ibm.team.process.internal.common.advice.runtime.OperationAdviceManager.runRunnable(OperationAdviceManager.java:1504)

      at com.ibm.team.process.internal.common.advice.runtime.OperationAdviceManager.execute(OperationAdviceManager.java:209)

      at com.ibm.team.process.internal.client.ProcessClientService.execute(ProcessClientService.java:774)

      at com.ibm.team.workitem.client.internal.WorkItemClient.save(WorkItemClient.java:573)

      at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyRegistry.saveWorkItems(WorkItemWorkingCopyRegistry.java:2320)

      at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyRegistry.saveAffected(WorkItemWorkingCopyRegistry.java:2211)

      at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyRegistry.save(WorkItemWorkingCopyRegistry.java:2094)

      at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyRegistry.save(WorkItemWorkingCopyRegistry.java:2055)

      at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyManager.save(WorkItemWorkingCopyManager.java:126)

      at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyImpl.save(WorkItemWorkingCopyImpl.java:243)

Note: It worked fine one year ago.
Is there any issue with this API?
Is there any API to remove change set link?

0 votes

Comments

the statement "it worked fine one year ago" means, with RTC 6.0.3 and 6.0.4



2 answers

Permanent link
The stack trace that is attached to this post is for a work item save. We would expect this to fail if the save attempted to add or remove a change set link.

A call to IFileSystemWorkItemManager#deleteLinks would remove the link from the server and then apply the link changes to the link manager so local copies of the work item can be updated. Is it possible you have an editor on the work item open or created a working copy of the work item before the link was removed. It is possible that the link was removed but the subsequent save of the work item working copy failed because it was not in-sync with the latest state of the work item.

1 vote

Comments
Thank you for your answer.
When calling remove link, I don't update anything on this work item.
And the link was NOT removed too.

Do we know why an exception from a call to fileSystemWorkItemManager.deleteLinks() is producing a stack trace for WorkItemWorkingCopyImpl.save() ?   

@gmclemm - is your question to the customer or to the development?

I'm happy for an answer from either source (:-), but I expect that we'd need one from development. 

@gmclemm @mvalenta - do you have any news on that?

We have discussed with Support, and for an RTC API, you can get help from IBM support by creating a simple program that demonstrates the bug when running against the sample project area ("Money that Matters").   That would be the best way to track this down. 

Thank you all for your supports.
It works fine on 6.0.6_ifix002.

showing 5 of 7 show 2 more comments

Permanent link

In my experience, the RTC SCM service reserves certain operations for itself. That means, there is a component ID that is associated to services such as SCM or work item etc. The operation checks the requests component ID and can reject operations that come from someone that should not request it.

Links of this type may only be modified by the defining component.
      Link Type: com.ibm.team.filesystem.workitems.change_set
      Defining Component: com.ibm.team.filesystem.workitems
      Requesting Component: com.ibm.team.workitem
This has always been the case. I remember that I ran into the same issue when working on the work item command line. I have also seen this in the server API.

In the server AI, you can basically use the component ID you want, when defining your server extension. I am not sure about what to do in the client API. I would search the SDK for where change set links are created and removed in the Client API and check if there is a method in one of the classes com.ibm.team.filesystem that does this and can be used instead.

0 votes

Comments

Having said that, if the same code worked for other 6.0.x versions, this could be an issue with the API. The Work item API is supported, so maybe asking support is an option. Ideally providing the source code. 

I'll ask development to take a look at this question, and add a response. 

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,019
× 369
× 149
× 49

Question asked: Sep 27 '18, 10:51 p.m.

Question was seen: 4,017 times

Last updated: Dec 18 '18, 10:01 p.m.

Confirmation Cancel Confirm