It's all about the answers!

Ask a question

Removing work items from change sets

Dinu Madau (52) | asked Dec 01 '15, 2:25 p.m.
 I have an issue with being able to deliver change sets between projects.  Let's assume the following configuration of RTC:
Project A
Project B

The main issue here is that work items and source code are not visible to users who are not members of the project areas.   This has had a significant impact on the day to day management of components that are reused in streams that are hosted in multiple project areas.  As it stands now, if Project A team makes a change associated with a Project A defect or work item, then that change set effectively cannot be delivered to Project B.  This is because although Project B team members are not members in Project A.   As a result, after the changes are promoted to the release stream, other team members cannot deliver the change sets into their own streams.  If they attempt to do so, the delivery fails because the filter script requiring an associated work item runs with the privileges of the user delivering the change set.  Because the user cannot see the associated work item (it being in a project that they have no visibility into), the filter fails as if no work item is associated at all.   Is there a way to strip away the work item from the change set and have the person in Project B create a new work item and associate it with the change set.  How would RTC handle a change set having work items associated from 2 project areas?  Is there any other solution to this short of adding visibility for all team members to all project areas or removing the pre-requisite of having a work item associated with a change set?

Accepted answer

permanent link
Geoffrey Clemm (30.1k33035) | answered Dec 04 '15, 12:05 a.m.
Another possibility would be to have all development done in Task work item types, which are linked to the appropriate Defect, Enhancement Request, and Story work item types.  The Tasks would only contain public information and are readable by everyone, while keeping the original Defects, Enhancement Requests, and Story work item types private.
Dinu Madau selected this answer as the correct answer

2 other answers

permanent link
Geoffrey Clemm (30.1k33035) | answered Dec 02 '15, 12:52 p.m.
I would suggest making the work items visible to all team members involved in the process.   If you are delivering code to a stream, you need to be able to see the works associated with the code you are delivering, in case you want to understand what you are delivering.   If they have a question about something being delivered, they can then add a comment to the appropriate work item.
Is there some reason why these work items need to be hidden?

Dinu Madau commented Dec 03 '15, 7:46 a.m.

  Team members are segregated by projects.  Everyone is not a member of all projects.  This is for security reasons.  We do not want folks that work on the Chrysler project to see what is going on in the Ford project since some of these folks are residents of the respective companies.  However, if we have a bug fix to software from a core subsystem team (e.g., Satellite  Radio) that needs to be applied to both projects we are unable to do this due to the visibility of the work items.  I realize that this can be changed in the process configurations operation behavior to not require work items in order to deliver code but that defeats the purpose.  There is another question in that is similar to mine: 

permanent link
Ralph Schoon (62.7k33643) | answered Dec 03 '15, 8:22 a.m.
Consider creating your own operation advisor that has a different behavior/logic, that suits you. For example the advisor can check is there is a work item associated - even if the user can't see it, I assume the permission aware API can at least tell there is an item, even if it can not be resolved.

Your answer

Register or to post your answer.