It's all about the answers!

Ask a question

how can we disable the resolve action on Duplicate linked workitems?


sam detweiler (12.5k6195201) | asked Oct 29 '12, 12:24 a.m.
when we mark another workitem as a duplicate of the current one, by creating a Duplicate of link, and save this workitem, the other end workitem is changed to Resolved (done/closed, ire its terminal) state

is there a was to disable this behavior?

Sam

Comments
Lauren Hayward Schaefer commented Oct 29 '12, 6:51 a.m.
JAZZ DEVELOPER

Hi Sam,
I just tried to duplicate what you described and I was unable to.  Can you provide more details like what version of RTC you're using and what the work item types are?  To make sure I understand your scenario:
1.  Open work item A.
2.  Go to the Links tab and add a link type of Duplicate Of that points to work item B.
3.  Save work item A.
4.  Then work item B is automatically set to the Resolved state?


Geoffrey Clemm commented Oct 29 '12, 6:36 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Whether or not adding a Duplicate Of link auto-transitions to Resolved depends on the work item type.   For example, in the Scrum template, this auto-transition occurs for Defect work item types, but not for Task work item types.

Unfortunately, I don't know whether/how you can disable this auto-transition functionality for work items that support it.  (That's why this is a comment, and not an answer :-). 


sam detweiler commented Nov 27 '12, 7:57 a.m.

hm.. I watch the forum EVERY DAY, and didn't see these posts til this morning..

Accepted answer


permanent link
Filip Wieladek (30413) | answered Nov 27 '12, 4:48 a.m.
Unfortunately, there is no way to configure the behaviour for auto resolution ( RTC 4.0.1 ) .

Currently, the code is hard coded to check for two workflow ids (bugzillaWorkflow or com.ibm.team.workitem.defectWorkflow) and applies the auto resolution behaviour. 

Therefore, the only way to disable this behaviour is to duplicate the existing workflow and assign that workflow to the defect work item type
sam detweiler selected this answer as the correct answer

Comments
sam detweiler commented Nov 27 '12, 7:42 a.m. | edited Nov 27 '12, 7:57 a.m.

interesting.. our defect workflow id is different.. will check. (3.0.1.1)
| well, the NAME is different, but the ID is the same.

we are SO close to deploying our customized template.. are there any issues with changing the ID value?  converting between types,  migrating data from projects that are on a prior template version and this one?...  sounds like a big a problem.


Geoffrey Clemm commented Nov 27 '12, 8:33 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

WRT changing the ID of the defect workflow ... probably worth making that a separate top level question.


sam detweiler commented Nov 27 '12, 8:48 a.m.

thx, will do.. side note, I wanted to submit an enhancement request to move this function into a process advisor/participant.. so it could be disabled as needed..  how do I do enhancements? I see record a bug?, but thats not right..


Geoffrey Clemm commented Nov 27 '12, 8:52 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

A "bug" is a generic term that some folks use to describe any work item.   I agree that this is misleading, so hopefully we can get that terminology fixed in the web page.


sam detweiler commented Nov 27 '12, 9:06 a.m.

but if you click there (create a bug), the type on the form is Defect only..  that means someone else has to come around and reclassify.. extra work.

also, that capability (force a particular workitem type) is not exposed to the public product.

One other answer



permanent link
sam detweiler (12.5k6195201) | answered Nov 27 '12, 10:56 a.m.
opened workitem 242467 to request moving this to a process advisor

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.