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
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?

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?

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:
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
Resolved.

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.

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
Resolved.

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.

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,

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