How can I prevent users from associating WIs from other projects with changesets being delivered to my project?
Hello: I am using RTC3.0.1.1 I would like to prevent users from associating work items from other projects with changesets being delivered to my project. I tried setting the "Require Work Items and Comment" precondition to check the box for "Iteration Work Item is Planned for: is required". That doesn't seem to check that the iteration is an iteration in the current project. It only checks that it is set to something. I would rather not check the "must be current iteration" because then I might interfere with developers who frequently merge changesets from stream to stream. The changesets that they are merging might have earlier iterations listed. (but I have not tested to verifyt that that would actually be a problem). It might also be a problem if we had multiple timelines (and thus a requirement to deliver to streams other than the current), but we don't for this project. -Thanks Maggie |
One answer
Geoffrey Clemm (30.1k●3●30●35)
| answered Oct 10 '12, 6:57 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I've filed work item Provide precondition that verifies that a change set can be delivered to a stream only if it is associated with a work item planned for that stream (236238) for this functionality.
|
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.
Comments
Can you expand a bit on what you mean by "change sets being delivered to my project" ? (A change set is delivered to a stream, not a project.) Perhaps ... "at least one of the work items associated with this change set must be Filed Against a category that is mapped to a team/project area that is (or is a child of) the team/project area that owns the stream" ?
Note: If that is what you mean, you would have to write your own custom precondition to check it.
I tried to comment and it says "Invalid".....so I'm commenting in the answer section.
Yes, Geoff, I would like to enforce that the work item has a "planned for" iteration that is an iteration in the project where the stream exists. At the moment, we are seeing deliveries associated with work items from another project and the team members of the stream's project aren't members or the other project and thus can't see the work item content.