It's all about the answers!

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

×42,860
×11,990

question asked: Mar 01 '16, 4:17 p.m.
question was seen: 1,961 times
last updated: Mar 02 '16, 5:48 p.m.

Related questions

how to stop the parent defect severity change when being marked as dup of the child defect?

0
Aparna Sukumaran (33●37●60) | asked Mar 01 '16, 4:17 p.m.
edited Mar 01 '16, 4:50 p.m.
When a defect is marked to DUP of another defect, RTC automatically change the severity of children defect onto parent's defect severity. For example, defect A has severity of S3 and defect B has severity of S2. Developer analyzed the issue and believe defect A is the same problem with defect B so he marked defect A as DUP of defect B. RTC automatically changed defect B (parent of the DUP) severity to S3 to match the defect A severity.
     This is a problem because a children defect should never update the severity of the parent defect.

RTC Version 4.0.7
Comments
Donald Nong commented Mar 01 '16, 9:12 p.m.

I tested in the JKE Banking sample project with RTC 5.0.2 and did not see such problem - severity remained the same. I could not locate a work item for any behavior change in this area. Do you have any customization in the process configuration?

One answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Don Yang (7.7k●21●114●139) | answered Mar 02 '16, 1:25 a.m.
edited Mar 02 '16, 1:27 a.m.
Hi, Aparna

I don't know if we should consider "duplicate of" as a parent-child link type. To me they should be the same level.
Yes, I do see the similar behavior in my local test, but it is not the same as what you described.

If defect A is severity 3 and defect B is severity 2(higher), if defect A is set as 'duplicate of' defect B, defect A will
be at resolved state and severity of defect B will not change because S2 is higher than S3(of the resolved duplicate defect).
If defect B is set as 'duplicate of' defect A, then defect B is will be at resolved state, severity of defect A will change to S2.
Although I can't find any explanation of this behavior anywhere, it does make sense to me that for the two duplicated defects, the higher severity should take precedence.  I don't see any way to workaround the issue unless the user manually update the severity after change.

If this behavior can be clearly documented, that would be helpful. In that sense, you may comment in this Infocenter to add more explanation on 'duplicate of/duplicate by' link:
http://www-01.ibm.com/support/knowledgecenter/SSYMRC_4.0.7/com.ibm.team.workitem.doc/topics/t_triaging_work_items_web.html?lang=en

Comments
Aparna Sukumaran commented Mar 02 '16, 1:57 p.m.

In my case severity of the original workitem is changed from S2-> S3 (it has lowered).
Is this anyway related to the Enumeration literals that we set up in the project area?

Literals Severity -  top down Lower to Higher severity. - It works as you explained

Literal Severity - Top down - higher to lower - Original work item severity is stepped down.

Don Yang commented Mar 02 '16, 5:48 p.m.

it is very likely the case that enumeration order of severity literals matters. The original severity is at the order of low to high. I guess the tool may actually looks at the id of the literals and the higher one will take precedence.(that explains why S3 or S2 may be used as the id of S3 is higher in your case and S2 is higher in my case)

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.