What use can be made of associating a change set with a work item in a different project area?
When associating a change set with a work item you may choose a work item in another project area. When would this feature be useful?
|
One answer
Geoffrey Clemm (30.1k●3●30●35)
| answered Jun 06 '14, 10:26 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
One use case would be where you have multiple CCM instances for storing components, but want to use a single CCM instance for storing all the work items.
Comments
Martin McAuley
commented Jun 06 '14, 10:34 a.m.
Thanks for the prompt reply. The case you mention is the only one I could think of, but having a global work item area seems more to overcome the problem of not being able to query across multiple project areas? Is it not more usual to have related components and work items in the same project area? In that case is there any benefit in being able to link change sets to work items outside the project area?
Geoffrey Clemm
commented Jun 06 '14, 3:46 p.m.
| edited Jun 06 '14, 3:49 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
It looks like I misinterpreted your original question ... a change-set belongs to a component, not a project area, and a component doesn't really belong to a project area (although it usually gets its read-access control from a particular project area). It is very common to have multiple project areas all make changes in a single set of components. On the other hand, a change-set does belong to a repository, and so I was interpreting your original question as being "choosing a work item in a project area in another repository". So probably a better answer to your actual question would have been:
Martin McAuley
commented Jun 10 '14, 4:44 a.m.
ok, thanks for the clarification, but regarding my original question, when associating a change set with a work item you can choose a work item from a different project area, when would that be useful?
Martin McAuley
commented Jun 12 '14, 5:27 a.m.
also your comment 'multiple project areas all make changes in a single set of components', if I understand correctly having read-access to another project area's component allows you to make changes to the component in your project area but you cannot deliver those changes back to the owning project area, for that to happen you would need to be a member of the owning project area - is that correct? If so, would that be a situation where it would be meaningful to associate a change set with another project area i.e. your workspace flows with a stream in one project area but you associate the change set with a work item in the other project area that owns the component?
|
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.