How Can I Allow a Follow-up Action to Fail but Still Save the Work Item?
This is similar to a question I have asked in the past, but there is an important distinction to my current situation that I'll try to distinguish. I have a follow-up action that modifies the parent of the work item being saved. If the parent cannot be modified, I want the current follow-up action to display a warning, but allow the save operation to succeed for the current work item. I've been able to do something similar to this in the past where a follow-up action would not prevent the work item from saving if I caught the exception thrown by the work item's save operation. However, this time that technique isn't working. The only thing I can think that is different is that previously the exception was being thrown by the save operation on the work item that triggered the follow-up action. By contrast, in my current scenario the parent work item's save operation is the one throwing the exception. In this instance, catching the exception doesn't seem to allow the follow-up action to save the child. Does anyone know how to do what I am trying to do? Ideally, I'd like to know whether the save operation on the parent is going to succeed without actually trying to do it. I think I've asked about that capability in the past though without success. Edit: Evidently I've asked this question almost word-for-word before. https://jazz.net/forum/questions/201697/server-side-java-api-how-can-i-determine-at-runtime-if-a-work-item-can-be-saved-without-trying-to-save I had convinced myself that I could do this by catching the exception. However, even if that is true it doesn't seem to be a valid solution for my current situation so I need another solution. |
2 answers
I'm sorry, I don't follow. follow-ups, run AFTER the save is complete.
if, in the followup, you invoke save again, then another entire sequence is run, advisors, then followups on THAT workitem (even if it is the same workitem) one workitem at a time. Comments Follow-ups run after, but if they fail they prevent the initial save from completing. I don't see entries in the revision history which indicate a change was committed and rolled back, so there must be some sort of soft-commit under-the-hood. If you have a chain of operation behaviors that modify X work items and then work item X-1 fails to save for some reason, all X work items will remain unchanged. I think I've noticed that if a follow-up action tries to create a new work item and then that follow-up action has to be rolled back, the work item's unique identifier is consumed, but no work item exists possessing that identifier. So on at least some level, changes are made on a preliminary basis. They just don't stick unless everything succeeds. hm.. ok, I understood it differently. but you may be right. It would make more sense I guess.
1
Geoffrey Clemm
commented Jan 05 '16, 8:57 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
It takes a bit of searching (:-), but in: https://jazz.net/wiki/bin/view/Main/TeamProcessDeveloperGuide#Adding_New_Operation_Participant , it says:
|
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.