Is there a precondition which checks for undelivered change sets when resolving a work item?
Users associate change set to a workitem but forget to deliver and proceed to "Close" the work item.
Is it possible in RTC out of the box to prevent the workitem not to set to "closed" status if there are associated change sets which aren't delivered?
Of course it is shown in the Pending changes as Outgoing changes but not all seem to care. I am not interested in customization as it is more effort and perhaps not worth the time.
Is it possible in RTC out of the box to prevent the workitem not to set to "closed" status if there are associated change sets which aren't delivered?
Of course it is shown in the Pending changes as Outgoing changes but not all seem to care. I am not interested in customization as it is more effort and perhaps not worth the time.
Accepted answer
There currently is no precondition that checks if there are undelivered change sets (or auto-delivers) when resolving a work item.
Part of the complexity here is that a Project Area and all of its child Team Areas may have hundreds of streams owned by them, how would each work item know which stream to check against? (also some work items may need to go to several streams). This would be a nightmare to setup/customize.
However, you can easily verify which work items (change sets) were delivered and which were not by using the Locate Change Sets editor. You would first create a work item query that is expected to find the relevant work items (ex: work items planned for a particular sprint for example). You then open up the Locate Change Sets editor and add the Stream(s) that you care about in the Search Targets section at the bottom. Now you can drag & drop the work item query to the "Change Sets" section at the top of the editor. This will automatically run the query for you and add the corresponding work items (change sets). Now select the stream(s) in the editor and click on the "Show Result Details" button. This will open the "Search" view with the results so you can inspect which work items (change sets) are included, and which are not included.
One other answer
Not that I would be aware. A tool can only do so much to fix sloppy work. This is also not trivial to do. You can spend a fortune on more and more checks, if users don't care they will find a way to introduce issues.
We have a view to "Locate change sets" where you can check if change sets linked to work items are in a stream or workspace. But I don't think that is really meant for hundreds of work items.
We have a view to "Locate change sets" where you can check if change sets linked to work items are in a stream or workspace. But I don't think that is really meant for hundreds of work items.