how to update menu selections on source actions, help
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
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
Comments
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.
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
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.
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.
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..
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.
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..
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.
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.
3 other answers
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.
what I meant was to change this setting:
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.
Comments
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.