It's all about the answers!

Ask a question

How to change the type of a new issue in RTC-SCM Code review component of 6.0.1?

Guido Schneider (3.4k1490115) | asked Jan 26 '16, 9:28 a.m.
retagged Oct 06 '17, 4:00 p.m. by Ken Tessier (84117)

Dear All,

we have upgraded to V.6.0.1 and are now introducing the SCM code review into the software projects.

Our internal process has already defined some workflows and wordings for source code reviews so we would like to follow this process.

In the SCM code review, if I create a new issue, I can give a "Type" to this issue. The type is a enumeration with following keywords: "Unspecified; Security; Accessibility; Best Practice; Globalization"

How is it possible to change this enumeration for a project area?
Can I change this in a way, that all project inheriting the process from a project area, automatically get the new enumeration/wording?

many thanks

Accepted answer

permanent link
Rick Maludzinski (561) | answered Jan 27 '16, 12:33 p.m.
edited Oct 05 '17, 11:11 a.m. by David Lafreniere (4.8k7)

In RTC 6.0.1 the issue types in Code Review are a fixed set. There was an enhancement request (369933), but we  ended up removing 'issue types' all together in 6.0.2. In RTC 6.0.5 we added the ability to allow the project administrator to define a set of tags that can be set on a code review issue. We expect this to be general purpose enough for customers to meet their workflow/process needs. For example, a set of tags could be created to represent the 'type' of the issue (ex: 'defect', 'best practice', 'question', 'invalid'), or to represent issue states such as 'verified', etc.

For additional information about RTC Code Review, please see:
Article: Rational Team Concert Code Review
Video: Introduction to Code Review (Part 1)
Video: Configuring Code Review (Part 2)
Video: Performing a Code Review (Part 3)
Knowledge Center: Working With the Code Review Tool

Guido Schneider selected this answer as the correct answer

2 other answers

permanent link
Piotr Aniola (3.7k11738) | answered Jan 27 '16, 7:00 a.m.
edited Jan 27 '16, 7:01 a.m.
I tried it just now, but it doesn't seem configurable. I will follow up on this internally to see if I missed how to configure it, or if I didn't can we make an enhancement out of it.

permanent link
sam detweiler (12.5k6195201) | answered Jan 27 '16, 7:38 a.m.
Absolutely.. If you use process sharing, then the child should get everything the parent has, including updates

EXCEPT if the child was allowed to make changes to the enum on its own.  If it is allowed (you didn't mark this 'final' in the parent), then IF the child changes the enum, it get s COPY of the list at that moment and is forever disconnected from future parent changes for (ALL) ENUMs.

you can test this pretty easily..
set final in the parent (shared) process config, and all children should see ONLY the parents config.
(ie, it will ignore completely any child configuration).
unset final and the child config will appear again.

this area is one of the sections that has child configurability allowed,  see

Guido Schneider commented Jan 27 '16, 7:45 a.m.

Hello Sam,

thanks for your answer.

I know process sharing and also delta configuration quit well.

But I have not found the enumeration of the source code review types. So I do not know how to change the default values, which doesn't make sense in our organization.


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.