Why does a failed work item save in a participant cause the entire save operation to fail?
![]()
Jared Russell (1.3k●1●20●19)
| asked Jul 31 '12, 6:32 a.m.
edited Aug 01 '12, 3:00 a.m. by David Olsen (523●7)
I'm developing a work item participant that is designed to create a new work item in a different project area if certain conditions are met. One of the scenarios I need to deal with is if the user that triggers the participant does not have access/permissions to create the work item in the target project area, in which case I want my participant to do nothing and let the save operation proceed as normal.
I have two questions:
1) Is there any API to check if the user that triggered the participant has permissions to create a work item in the target project area? My approach so far has been to attempt the save and catch resulting TeamRepositoryException, which leads me to my next question...
2) I've wrapped the call to the IWorkItemServer#saveWorkItem2() call in a try/catch, with the catch block just silently ignoring the exception. Despite this, when I trigger the participant with a user that lacks permissions in the target project area, it causes the overall save operation to fail with an error message of "'Save Work Item' failed. Permission denied."
Things I've tried:
This behaviour seems to indicate that the failed attempt to save the work item in the other project causes some sort of global state to be set that prevents the operation from completing successfully. How can I prevent this failed save from causing the entire operation to fail?
|
Accepted answer
2 other answers
![]()
Ralph Schoon (62.7k●3●36●43)
| answered Jul 31 '12, 7:58 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Jul 31 '12, 7:58 a.m.
My take on it is, the check is done at a repository level. No matter how you wrap the operation, if the user has no permission - he has no permission. You can either give him permission or he chooses to save in a category where he has permissions.
It is probably very hard to check if the user has permission and the whole mechanism allows to create and edit. The permissions are checked when doing the save. I also think it would be bad design if you could circumvent such basic permissions. Comments If the user has no permissions to create the work item then that's fine - as I mentioned I'm happy to not create the other work item and let the save operation continue. My question/problem is that RTC doesn't seem to let the save of the work item continue if the creation of the other work item fails. If I can't check the permissions that's also fine, I just need a way of allowing the save to continue and not throw an error message. ![]() FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Jared, are you sure you caught all exceptions? I assume if you fail to create the work item if you wrap that and catch everything you should be able to continue gracefully. I am wondering what you did not catch. @rschoon 100% sure - as I mentioned in my original question I wrapped my entire run() method in a try/catch, and I can see in the debugger that the catch block is getting hit when the the attempt to create the other work item fails. Despite this the operation to save the work item that triggered the participant still fails with the permissions error. ![]() FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I will try to find some time to do the same stunt 8-) ![]() FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Um, I would not wrap the run() method, but the call to create/save the work item (maybe I am miss interpreting something) inside of the participants run() operation. @rschoon Wrapping the entirety of the run() method was done as an option of last resort to make sure there were no other exceptions being thrown - obviously for my production code I'd only catch the exception from the save operation
showing 5 of 6
show 1 more comments
|
![]()
AdvisableOperation is the parameter that gets passed to the advisor extensions.
the help for that datatype says (I have never built one to pass to advise)
An operation advisable by process. Advisable operations can be configured by end users with pre-condition checks (@see
Advisable operations must be declared via extension so that clients can view the list of available operations to configure when authoring their process. Advisable operations are declared on the client as elements of the extension point
For example: <extension point="com.ibm.team.process.client.configurationPoints"> <operation id="com.ibm.example.operation" name="Example Operation"> <action id="foo"> <action id="bar"/> </action> <action id="foo2"> <action id="bar2"/> </action> </operation> </extension> Advisable operations may not be executed by clients directly. They should instead be passed to the advise and execute methods on the client or server process (@see com.ibm.team.process.client.IClientProcess and com.ibm.team.process.service.IServerProcess).
Comments >Advisable operations must be declared via extension so that clients can view the list of available operations to configure when authoring their process
|