Removing work items from change sets
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
Geoffrey Clemm (30.1k●3●30●35)
| answered Dec 04 '15, 12:05 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Dec 02 '15, 12:52 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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? Comments 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 jazz.net that is similar to mine: |
Ralph Schoon (63.1k●3●36●46)
| answered Dec 03 '15, 8:22 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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
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.