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

Server-Side Java API - How Can I Determine at Runtime if a Work Item Can Be Saved Without Trying to Save

Questions
Tags
Users
Badges
Nate Decker
(378●1●47●61) edited
Dec 04 '15, 4:24 p.m.

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

0 votes

Comments
sam detweiler
Dec 04 '15, 11:47 p.m.
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..

Nate Decker
Dec 14 '15, 9:58 a.m.
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.

1 answer
7,003 views
0 votes

One answer

Permanent link
sam detweiler
(12.5k●6●195●201) Jul 09 '15, 12:21 p.m.
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. 

0 votes

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.

Ask a question
Guidelines
FAQ
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
× 11,106
× 419

Question asked: Jul 09 '15, 9:05 a.m.

Question was seen: 7,003 times

Last updated: Dec 14 '15, 9:58 a.m.

Confirmation Cancel Confirm