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

how to update menu selections on source actions, help

Questions
Tags
Users
Badges
sam detweiler
(4.1k●3●12) 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

0 votes

4 answers
243 views
0 votes

Accepted answer

Permanent link
sam detweiler
(4.1k●3●12) 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

0 votes

Comments
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jan 18 '13, 11:50 a.m.
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
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
JAZZ DEVELOPER Jan 18 '13, 12:09 p.m.
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
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jan 18 '13, 12:17 p.m.
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
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
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jan 18 '13, 12:33 p.m.
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
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
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jan 18 '13, 1:28 p.m.
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
JAZZ DEVELOPER Jan 18 '13, 2:40 p.m.
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

Permanent link
Tim Mok
JAZZ DEVELOPER (4.4k●3) Jan 18 '13, 11:03 a.m.
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.

0 votes

Comments
Tim Mok
JAZZ DEVELOPER Jan 18 '13, 11:11 a.m.
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.

Permanent link
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (21.1k●2●9) Jan 18 '13, 10:45 a.m.
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 votes

Permanent link
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (21.1k●2●9) Jan 18 '13, 10:13 a.m.

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.

 

0 votes

Comments
sam detweiler
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).

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
× 1,445
× 127

Question asked: Jan 18 '13, 8:41 a.m.

Question was seen: 243 times

Last updated: Jan 18 '13, 2:40 p.m.

Confirmation Cancel Confirm