Prevent associating a change set to a work item that already has delivered change sets associated to it
mark byrd (147●1●23●30)
| asked Aug 19 '13, 9:42 a.m.
edited Aug 02 '16, 6:24 p.m. by David Lafreniere (4.8k●7)
I don't want a developer to be able to associate a change set to a work item that already has delivered change sets associated to it. I see that advisor "prevent linking to approved work items" can do this if approvals are used. I have a situation where delivery to a test stream does not require approval, but delivery to an integration stream does. Is there a way to programmatically(RTC Java API) determine whether a work item already has delivered change sets? Alternatively ... is there a way to automatically add an approval on delivery to the test stream?
|
Accepted answer
Ralph Schoon (63.5k●3●36●46)
| answered Aug 19 '13, 9:56 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Mark,
If you require such custom operational behavior, you would have to create your own operational behavior. An Advisor (pre-condition) can prevent from saving. You could create an advisor for the work item save operation that would detect if the work item is already associated to a change set and prevent saving in this case. A change set is associated using a link/relationship. I have several examples on https://rsjazz.wordpress.com/ that should help you get started. https://rsjazz.wordpress.com/2012/11/01/restrict-delivery-of-changesets-to-workitem-types-advisordelivery-of-changesets-associated-to-wrong-work-item-types-advisor/ is an advisor (but for deliver). The blog also links to where to find the operation ID's and how to get started. You can search the blog for hints. There is, for example, a follow up action and other code that allows you to analyze the relationships of a work item. https://rsjazz.wordpress.com/2012/07/31/rtc-update-parent-duration-estimation-and-effort-participant/ shows code for a participant, but a lot of that API code can be used for what you are trying to do or points into areas you should look at (e.g. the link types). mark byrd selected this answer as the correct answer
Comments I didn't want to "reinvent the wheel" if there was a "canned" advisor that I'd missed that might help with this issue. I've received these links from you before on a previous post, and they helped with a previous issue. I will dig through them some more on this issue. Thanks. |
One other answer
There are a couple preconditions that might fit what you want.
Prevent Linking to Approved Work Items - Prevent change sets from being linked to work items that have already been approved. Restrict Associating To Closed Work Items - Prohibits adding and removing change sets to closed work items. You could use the Prevent Linking to Approved Work Items precondition on your test stream but treat the approval as "I have delivered". If your work items are closed, you can use the second precondition to prevent new change sets being associated. You might want to consider changing your team's work flow to adapt to the process. Set your work items to resolved when the work has been delivered to the test stream. When they are in the production stream, you can verify that the change sets are in the stream and set the work item to verified. That's just an example of how you could work. I'm not exactly sure what you want since your question says your test stream doesn't require approval but your clarification to Geoff's response says your QA stream requires approval and your dev stream is the one that doesn't require approval. |
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.
Comments
Just for interest's sake, why are you preventing delivery of additional change sets associated with a work item? It makes sense if you have some kind of approval process in place (since you don't want unapproved change sets to be delivered), but why force a developer to associate a new work item for a delivery, if logically the purpose of the new change set is to complete the work defined by the existing work item?
We have three streams (dev, qa, prod), Using Teams, we require unique approval when delivering to qa (review) or to prod (approval), but not for delivery to dev. Once a work item has been used for change sets that were delivered to qa or prod, I don't want it used for changes sets that will be delivered to dev. If it was, the previous approvals for qa and prod would apply to the new change set. Management does not want to have to approve delivery to dev. If I could automatically add an approval (say a verification approval) upon delivery to dev, I could use the "prevent linking to approved work items" advisor. Otherwise I think I would have to prevent associating change sets to work items based on other work item attributes.