It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,880
×10,916

question asked: Jul 24 '13, 1:41 p.m.
question was seen: 5,262 times
last updated: Aug 08 '13, 9:08 a.m.

Related questions

"Delivery" vs "Delivery and Resolve Work Item"

0
Kelvin Lui (51●2●9●9) | asked Jul 24 '13, 1:41 p.m.
 By default RTC provides these two options to deliver changeset to the stream.
- Deliver
- Deliver and Resolve Work Item

Assume there is two extension plugins associated with these two actions being triggered (I may be wrong) My question is:

- does these two actions implement as into two separate extension plugins? if yes do they declare its own extension point such that they could be extended by additional extension plugin?
- does these two actions extend the same extension point: com.ibm.team.scm.server.deliver 

Thanks.



3 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Tim Mok (6.6k●3●8) | answered Jul 24 '13, 2:22 p.m.
JAZZ DEVELOPER
I'm not sure what you want to do here. The actions are implemented by separate plugins due to the way we separate the dependencies on other components. The underlying operation is different for each action except that the deliver and resolve operation creates a deliver operation to perform the deliver part.

If you're referring to com.ibm.team.scm.server.deliver, I'm not sure what you mean. There is a permission id by that name and the permission to deliver is checked with both actions.
Comments
Kelvin Lui commented Jul 24 '13, 2:29 p.m. | edited Jul 24 '13, 2:37 p.m.

 the challenge we have is for "Deliver and Resolve Action" it will change the WorkItem to state 1 to state 2.  However our customized process requires for the state remains the same if a changeset is delivered to specific stream.


So we try to find out if the extension plugin ("Deliver and Resolve Action") has its extension point and we can update/change the state back to the original one.

Or is it possible that I could just implement a new extension plugin to change the state back to the original one, and this extension plugin will be executed after the "Deliver and Resolve Action" Extension Plugin is executed.

Thanks for your advise.

Tim Mok commented Jul 24 '13, 2:40 p.m.
JAZZ DEVELOPER

I'm still not quite clear what you want to do. What's the work item state that changes? The deliver and resolve action will resolve the work item and do a couple other things if you choose. I don't know what part you don't want to change but it sounds like the deliver and resolve action is not what you want to do.

Kelvin Lui commented Aug 07 '13, 2:21 p.m.

k so there are two extension plugins deployed for each action:

- Deliver
- Deliver and Resolve Work Item

Does the plugin "Deliver and Resolve Work Item" define with its own extension point such that it could be implemented by another plugin?

Tim Mok commented Aug 07 '13, 2:30 p.m.
JAZZ DEVELOPER

No, it does not provide an extension point for you to extend. It's just an action that executes an operation based on the selection. You could reimplement this and do whatever you want but it does sound more like you should have a precondition on the work item save. Run your checks there and prevent the work item from saving based on your conditions.

0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Jul 24 '13, 8:48 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Jul 24 '13, 8:57 p.m.
I'll make a few assumptions.
First, I assume you are asking about the behavior of the "deliver and resolve work item" request (and not the "deliver" request).
Second, I assume by "extension plug-in associated with an action", you are referring to something like a precondition or follow-up action associated with an action.
Third, I assume when you say "two extension plug-ins associated with these two actions", you mean one extension associated with the "deliver" action (e.g. a deliver precondition) and another that is associated with the "resolve work item" action (e.g. a save work item precondition).

This is my understanding of how it works.
The "deliver and resolve work item" effectively invokes two actions: the deliver action and an edit/save action on the work item.  All extensions of the deliver action and all extensions of the edit/save action will be invoked when you perform a "deliver and resolve work item".   I did a quick test, and it appears to invoke all of the pre-conditions before invoking the actions (as one would expect), since if either a deliver precondition or a save-work-item precondition fails, then neither the deliver or the resolve-work-item actions are performed.   But I haven't had a chance to experiment with the follow-up actions.  Ideally, I'd like all actions and their follow-up actions to be performed in one database transaction, so if any of the actions or follow-up actions fail, then no changes are made to the database.   But it is possible that what is actually done is that each action with its follow-up actions are performed in a separate transaction.  If that is the case, then the question is what is done when one of the follow-up actions fails ... are the rest of the actions skipped, or are they attempted?  Does anyone know which is the case?
0
permanent link
sam detweiler (12.5k●6●195●201) | answered Aug 07 '13, 5:22 p.m.
we had an issue here too, the resolve action puts it into the closed group resolved state.

our next workflow state was not 'resolved', but 'implemented' with verified and resolved after that.
Comments
Susan Hanson commented Aug 07 '13, 10:11 p.m.

my understanding of "Deliver and Resolve" is that it does the deliver and then it runs the action defined on the workflow for the work item type.  So if the action defined in your workflow as the "resolve action" moves it to a closed group, then I could see how that happens.  But for example, our Defect Workflow has the "Resolve action" defined as "Fix Finished" and that action has a Target State of "Ready" and that State is in the In progress group.

Susan

Tim Mok commented Aug 08 '13, 9:05 a.m.
JAZZ DEVELOPER

Deliver and resolve won't do what you want. It puts the work item in the first resolved state that it retrieves. If you have multiple resolved states then there's no guarantee it will pick the state that you want. If your state for implemented is not set as a resolved state then the action will never use that state.

sam detweiler commented Aug 08 '13, 9:07 a.m. | edited Aug 08 '13, 9:08 a.m.

yeh.. the problem is the darned USERS pick this cause its 'faster'.. but it screws up all the reporting cause u have to use re-open to get it back from the accidental early resolved state. then the counts of re-opened are invalid.

really need to remove this option from the menu.

Your answer

Register or 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.