It's all about the answers!

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

×42,884
×6,115
×1,201
×127

question asked: Jan 18 '13, 8:41 a.m.
question was seen: 5,854 times
last updated: Jan 18 '13, 2:40 p.m.

Related questions

how to update menu selections on source actions, help

0
sam detweiler (12.5k●6●195●201) | asked Jan 18 '13, 8:41 a.m.
edited Jan 18 '13, 8:43 a.m.
on our Defect workflow we have added process flow before Resolved state

in progress
implemented
verified
resolved

however, there is a Source code action, Deliver and Resolve, which is causing us problems.

is there any way to change the context menu selections? cause in our case it should be
Deliver and set Implemented

Accepted answer

0
permanent link
sam detweiler (12.5k●6●195●201) | answered Jan 18 '13, 11:39 a.m.
unfortunately these answers are not correct

1. if you mark a workitem as the target of  'duplicate by' it will be forced Resolved.. the above setting would affect that.
2. our workflow is inprogress thru verified are in the open state. only after verification is it resolved.
    so the developer can NEVER 'resolve' the workitem on checkin to the stream.
 
I am the designer of the workflow, to meet our business requirements and these hard coded side effects are really causing us trouble.. (the closure of the dup is also hard coded, but only for some workflows by specific ID, enhancement request opened and closed as dup, but dup is wrong).
dup closure enhancement request

Ralph Schoon selected this answer as the correct answer
Comments
Ralph Schoon commented Jan 18 '13, 11:50 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Sam, in that case, an enhancement request is in order. I think it would be very hard to  remove the action that is available. Eclipse has no real means to remove entries. You can do that by manipulating the plugin.xml's, but that is pretty dirty. Just renaming won't work either. You could add you own menu action, if the menu path allows to add custom menu entries. I have done things like that in the past. But I don't know the paths/id's needed to hook up your own menu contribution in this case.

sam detweiler commented Jan 18 '13, 11:58 a.m.

thanks.. unfortunately OTHER workflows MIGHT support Deliver and Resolve..  so its not as easy as changing a menu.. forcing the two step process might be the only way

I'll open an enhancement regardless

Tim Mok commented Jan 18 '13, 12:09 p.m.
JAZZ DEVELOPER

For the source control side, we're only calling what is provided by work items as the resolved state. If you don't intend "implemented" to be a resolved state, there isn't anything you can do to remove the "Deliver and Resolve" menu entry or have it move your work item to the "implemented" state.


What if you try setting the workflow so that a work item can't transition from "implemented" to "resolved"? Trying to "Deliver and Resolve" would stop the process if the work item is in the "implemented" state. Although, it would still go through if the work item is in a "verified" state since it seems that's the only valid transition to "resolved". You can probably stop that by creating your own operation advisor to disallow delivery when the work item isn't in the "in progress" state.

Ralph Schoon commented Jan 18 '13, 12:15 p.m. | edited Jan 18 '13, 12:17 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Invalidate (selecting none) the resolve action for this work item type might be a way. Otherwise here is some code that you could even potentially use to detect the action and drive the work item into a more convenient state in a follow up action. Not sure it would look pretty though.

sam detweiler commented Jan 18 '13, 12:27 p.m. | edited Jan 18 '13, 12:27 p.m.

Our root problem is that because of the Duplicate side effect mentioned above, we MUST have Resolve from any state. We don't WANT that, but its hard coded, and if the remote end link save fails, then this workitem save fails.  I want to write my own participant for this, but can't.

now that I am forced to have Resolve from any state (our workflow now looks like a bowl of spaghetti), I fall into these other side effects that are causing problems..

Ralph Schoon commented Jan 18 '13, 12:33 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Sam,

have you considered to write an advisor that fails the resolve state change for this specific workflow and situation? This would render the menu action useless in this specific case, but the users could still deliver and change the state as required. I think that would also happen if there is no transition from InProgress to resolve.

sam detweiler commented Jan 18 '13, 12:52 p.m.

Enhancement

I sure wish I could remove the transition to Resolve, but can't due to the hard coded Duplicate  action.

but your suggestion is just another ugly hack that upsets our users..
you give us a menu item that doesn't work.
and I don't see how you could do this in an Adivsor.. I suspect they are two operations, and I would only see the change to Resolved which MUST be supported due to the Duplicate problem a anyhow.

otherwise I would have to write two advisors.. one for deliver and one for resolve and somehow I would have to tie them together and reject the resolve action..
the technical debt keeps climbing..

Ralph Schoon commented Jan 18 '13, 1:28 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I can't fix what is, I can only try to provide ideas how to work around current limitations. If that is not enough, then consider an ER or PMR.

Tim Mok commented Jan 18 '13, 2:40 p.m.
JAZZ DEVELOPER

I think it would make most sense to have a deliver advisor that prevents delivery when the work item isn't "in progress". I think this would be pretty simple to do. No custom advisor when resolving a work item is needed. It would have a similar style of behaviour as other advisors that restrict associating a work item that is already closed. The purpose of the advisor is to impose a pre-condition before an operation occurs. It's just different in your case because you never want "deliver and resolve" to happen. I think it's best to have this kind of advisor because you wouldn't want someone to deliver code associated with a work item that isn't at the "in progress" state.

showing 5 of 9 show 4 more comments

3 other answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Ralph Schoon (63.6k●3●36●46) | answered Jan 18 '13, 10:13 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Hi Sam,

did you try to set the resolve action in the workflow you are changing to an action that goes into implemented? That should trigger the right workflow action on deliver and resolve.

It is possible to chage the menus in Eclipse, you would essentially have to change the plugins with the messages. I would suggest not to. It is messy and you would have to do it for each update. If you can live with the action name in the menu the resolve action should do what you want.

 

Comments
sam detweiler commented Jan 18 '13, 10:21 a.m.

sorry, I'm not sure I understand what you are suggesting.

let me repeat:

you are suggesting replacing the 'Resolve' Action in our workflow with something that does NOT Resolve?  so I have a fake Resolve action (sets implemented) and a real Resolve action (sets resolved).

0
permanent link
Ralph Schoon (63.6k●3●36●46) | answered Jan 18 '13, 10:45 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Sam,

what I meant was to change this setting:

Resolve Action

To my knowledge that setting is used to run the selected action on deliver and resolve. If you select the action that is appropriate to you, the workflow would work.

To finally resolve the workitem (or whatever action is used) you would still be able to trigger that action n the workitem editor.
0
permanent link
Tim Mok (6.6k●3●8) | answered Jan 18 '13, 11:03 a.m.
JAZZ DEVELOPER
The "Deliver and Resolve" operation does as it implies. It delivers the change set and resolves the work items that are associated. If your "implemented" workflow state isn't a resolved state, it won't set your work items to that state. The operation also doesn't handle multiple resolved states very well. It just takes the first resolved state and uses it to resolve the work item.

Your intended workflow also seems different than what is expected. The default workflow for a defect is resolved then verified (in terms of the defined states in the process configuration). If you set your "implemented" state as the resolved state, and as your only resolved state, invoking "Deliver and Resolve" will go to "implemented" for you. Although, this will impact your work item queries and other things that treat resolved work items differently.
Comments
Tim Mok commented Jan 18 '13, 11:11 a.m.
JAZZ DEVELOPER

I tried some things out and Ralph's answers is correct. As long as the current state of the work item changing to "implemented", is a valid workflow defined in your process configuration.


Only change your "implemented" state to a closed group state if you intend it to mean it's resolved. Otherwise, the default resolve action is good enough for you.

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.