RTC Associate work item mandatory
Hi,
We are using RTC for Source Control, Build and defect Tracking. RTC allows to checkin the code without associating to a work item. We are having problems in tracking. We want each changeset to be associated with a workitem as process. Please let me know how to we do the following in RTC. 1. All changesets should be mandatorly associated with a work item. 2. After the Build the state of work item should be changed to Resolved. How do I do the following. Thanks, Bharani J |
5 answers
Hello,
this can be achieved by adding corresponding pre-condition in the Project Area. See http://publib.boulder.ibm.com/infocenter/rtc/v2r0m0/topic/com.ibm.team.scm.doc/topics/t_scm_eclipse_process_preconditions.html and http://jazz.net/library/article/137 for more details. Thanks. Eric. bharani a crit : Hi, |
bharani wrote:
1. All changesets should be mandatorly associated with a work item. I don't know of a way to force a change set to be associated with a work item when it is first created. But you can force the change set to be associated with a work item before it can be delivered to a stream. To do that add a precondition to the deliver action in your team's process. (And delivery to a stream is exactly when you want to enforce this. As long as the change set stays in the repository workspace and is never delivered, it can't have any real effect on anything, so you shouldn't care whether it is associated with a work item or not.) 2. After the Build the state of work item should be changed to RTC can't do that automatically. You aren't the first to ask for it. (But if there is an existing enhancement request filed against RTC for this, I can't seem to find it.) The best approximation I can think of is to create a query that lists all unresolved work items with an "Included in build" relationship. Run the query and resolve all the work items it identifies. Not fully automatic, but not too cumbersome. |
Geoffrey Clemm (30.1k●3●30●35)
| answered Nov 18 '09, 8:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Note that one of the reasons it is problematic to "auto-resolve" work
items is that work item process will often require that additional fields be set to mark a work item as resolved, and if the attempt to resolve the work item fails, its unclear how to report that problem. You could fail the build, but that doesn't seem right. You could make it a warning, which is better, but still somewhat misleading (and could easily be missed ... who looks over the warnings anyway :-). Or you could automatically add a comment to the work item (that is probably what I'd do). Or you could allow the user to specify as build parameters the required attribute values. So it can get quite complicated. Cheers, Geoff David Olsen wrote: bharani wrote: |
I'm aware of the preconditions associated on a delivery, enforcing the existence of a work item with the owner set to current user. There are some at my organization that strongly desire RTC to enforce the same rules that that existed using UCM with ClearCase/ClearQuest. This would be that a developer cannot checkout/checkin any files without an assigned ClearQuest record. In RTC, this equates to the ability to save changes only if a work item is set to "start working". Is this possible?
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Dec 10 '09, 12:08 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I would strongly recommend that no such restriction be placed on an RTC
workspace checkin. A repository workspace is designed to be a private place within which a developer is free to do whatever they wish. Trying to control/limit what a developer can do in a repository workspace just forces the developer to work outside the system (which they can easily do), but this benefits neither the developer or the team. Cheers, Geoff vrcampbell wrote: I'm aware of the preconditions associated on a delivery, enforcing the |
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.