1) Create N change sets.
2) Create Work Item A (and make a comment).
3) Associate the change sets with Work Item A.
4) Acquire approval for Work Item A.
5) Create additional change set(s) and associate them with Work Item A.

What we've done is piggy back on the state of the work item to help restrict when change sets can get attached to work items. It's quite common that you work away and associate changes with work items over a period of time.

The pre-condition you mentioned "retrict associating change sets to closed work items" is meant to allow you to control when change sets can get added/remove from work items based on the state of the work item. It can also add an audit trail (comments) to the work item when change sets are added and removed. The scenario we wanted to support involved the developer marking the work items as done, but not reviewed, and then adding reviewers to review and change the state to closed/reviewed. You can further control who can re-open a work item using perimssions.

Hi Jean-Michel,

can you expand on that? I am looking into RTC 2.0.0.2 and can not find a way to restrict adding change sets to states except the closed states precondition.

I am looking into supporting a customer getting more SPICE compliant (automotive) /increase maturity and approvals are important here. What I would like to do is similar to above. More specific:

1. In a certain open state "Implement" the developer can associate change sets.
2. Transitioning into a state "Pending Verification". Being in this state would not allow to add additional change sets.
3. Transitioning from there into state "Verified" would requires an approval of a certain type

Please note "Verified" would not necessarily be a closed state. I would like to be able to daisy chain several of the state chains like above. E.g. a similar behavior like above for analysis before implementation.

Using the precondition "restrict associating change sets to closed work items" would require "Pending Verification" to be a closed state - which I don't want due to the planning component.

I am also looking into using hierarchy to avoid the "daisy chaining" - having several series of the behavior above in a work item workflow. But again the state I want to stop accepting change sets applied is not supposed to be a closed state because i don't want it to show up as closed in planning.

BTW: the requirement expressed here comes up with the current ability to assign change sets AFTER an approval has been given without making the approval invalid. I agree that the state solution is great and maybe the only practical one but to make it complete a solution would have to allow me to pick an arbitrary state and allow or restrict me to assign change sets.

If tying the condition to a state grouping a configurable state attribute (besides the built in groups "None, Open, In Progress, Closed") for grouping would be great.

Ralph

1) Create N change sets.
2) Create Work Item A (and make a comment).
3) Associate the change sets with Work Item A.
4) Acquire approval for Work Item A.
5) Create additional change set(s) and associate them with Work Item A.

What we've done is piggy back on the state of the work item to help restrict when change sets can get attached to work items. It's quite common that you work away and associate changes with work items over a period of time.

The pre-condition you mentioned "retrict associating change sets to closed work items" is meant to allow you to control when change sets can get added/remove from work items based on the state of the work item. It can also add an audit trail (comments) to the work item when change sets are added and removed. The scenario we wanted to support involved the developer marking the work items as done, but not reviewed, and then adding reviewers to review and change the state to closed/reviewed. You can further control who can re-open a work item using perimssions.