Server-Side Java API - How Can I Determine at Runtime if a Work Item Can Be Saved Without Trying to Save
I have several follow-up actions that save a work item subsequent to the operator saving that work item. In certain cases, the follow-up action may not be able to save the work item. It's failure would prevent the user from saving the work item as well. In many of these instances, I would prefer for my follow-up action to just exit gracefully and allow the operator's save to complete unfettered. Is there a way in the server-side Java API to check whether a saveWorkItem3 operation would be successful without actually trying to perform the save? I thought that maybe I could just catch the exception that is thrown if the saveWorkItem3 operation fails, but I think I tried that and it still halted the user's manual save action. I thought I had read that this was possible in a forum posting at some point, but I've been unable to find it. Edit: I had forgotten that I had an unresolved question on this subject already so I ended up asking the question again here: https://jazz.net/forum/questions/212374/how-can-i-allow-a-follow-up-action-to-fail-but-still-save-the-work-item |
One answer
I looked thru the methods available to AbstractService and IOperationparticipant and don't see any verification methods.
you CAN do this for Advice (advisors) on with the AdvisableOperation class (1st parm to the participant) using the public abstract IOperationReport run(IBehaviorConfiguration configuration, IProgressMonitor monitor) throws TeamRepositoryException; but I don't see anything on Participants pre-check. |
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.
Comments
Nate,
"I would prefer for my follow-up action to just exit gracefully and allow the operator's save to complete unfettered"
the operators save has already happened before the FOLLOW-UP actions are executed. The operator specified data is committed to the database already.
I understand you would like to gracefully exit if a subsequent save (save_workitem3) failed.. but it would fail because the advisors prevented it AND put the message in the 'to display' buffer..
Sam,
In my experience if a save action triggers a follow-up operation behavior and that operation behavior throws an exception, the save action fails and the work item is left unchanged. I've seen this behavior many times. It's actually rather useful because I can leave my client active, fix my operation behavior and then just click on "save" again in the client to test the fix.
So it would appear that no real commit happens until all pre-conditions AND follow-up actions complete successfully. In my case, this means that because my follow-up action fails due to a permissions problem, the initial save also fails. When this happens, it can be super confusing to the end-user as to why their save didn't work.