In CRs, the "Addressed In Build" and "Last Build Tested" do not have build labels created in other views in the dropdown list
Product version: StarTeam 5.2.196 and earlier 5.x
Applicable component: Build Labels
In Change Requests, the "Addressed In Build" and "Last Build Tested" do not have build labels created in other views in the dropdown list. When using a centralised project for CRs the label is created in the CR view, then the Next Build value can cause incorrect build labels to be assigned to the CRs if they relate to different views that all have view. The primary cause of this is the fact that view labels to are local only to the view in which they were created.
Resolution: The following is one possible solution. It is not the only possible solution and other variations on this are also possible. The basic idea is to use sharing to make the CRs visible in both the centralised project and the development project where the labels will be created.
Example: StarTeam projects: Defect Management: Centralised project used to manage defects. Project A, Project B, Project C: Development projects. Create folders in Project A, B and C to store the defects. Make sure that the name of the folder includes the project name, e.g. Project A Defects This is how developers will access the defects related to their own projects. Share these folders into the centralised Defect Management project. This will be the location where the defect managers and projects managers will manage the defects. Defects can now be created either in the Defect Management project, or in project A/B/C, and it will be visible in both locations. When developers set the defects to Fixed in Project A/B/C then the AddressedIn field will be set to Next Build, and the dropdown list will be populated with the Build labels that exists in those projects. The selected value will be visible in Defect Management, even though the Build label does not exist in that project. For the Next Build value it will be set to the first Build Label that is created in any view where the defect is visible. No build labels should be created in the Defect Management project, so that the defects will only be updated when new builds are created in the development projects.
Notes: When moving or deleting shared CRs only the one side of the CR is actually moved. The other side is not affected at all, so it may cause your shared folders to become out of sync if the same operation is not done on both sides of the share.