It's all about the answers!

Ask a question

Can I require approval for Change Sets?


Brian Murray (1153) | asked Apr 30 '10, 3:33 p.m.
I'm using RTC 2.0.0.2.

Our process customization at present is set up to "Require Work Item Approval" and "Require Work items and Comments" prior to Delivering Change Sets. However, this doesn't restrict the following path:

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.

How do I extend my options? (Right now I see 7 possible preconditions for "Deliver", none of which are "Require Change Set Approval".)

Note: I do see that I have the option to "Restrict Associating To Closed Work Items" for Saving Change Set Links. Maybe the best solution is to generate a "Restrict Associating to Approved Work Items" possibility. Is this something I can do / should be doing?

2 answers



permanent link
Jean-Michel Lemieux (2.5k11) | answered Apr 30 '10, 9:58 p.m.
JAZZ DEVELOPER

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.

permanent link
Ralph Schoon (63.1k33646) | answered May 01 '10, 10:26 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.

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.