[Require work items and comments] precondition: how to ignore the other associated work items when replacing the components?
We use RTC 4.0.1 and have the below use case:
[Require work items and comments] precondition is set for Deliver(Server) for developer and configuration admin roles. When the developers deliver the changesets to one stream(stream1 for example), they all have workitems associated with the changeset. This works as expected. We need to sync another stream(stream2 for example) with stream1, we have Configuration Admin to replace the component in stream2 with the components in stream1. When doing this, the precondition throws many errors(same error for each associated workitem): You must own the workitem associated with the change set. The Configuration Admin does not want to re-associate those workitems by the original developers. If we remove the precondition from the configuration admin role, "You must own the workitem associated with the change set" is gone, but configuration admin is not forced to associate the workitem for his action which we need to do the search later on. How can we achieve the scenario that: not to throw any errors for the already associated workitems by other developers but force the configure admin to associate his own work items? |
2 answers
Unfortunately, you have conflicting pre-conditions and the out of the box pre-conditions cannot be configured for your use case.
One way you can work around this is to associate one work item to the change set (or however many is required by the developer). When the configuration admin gets the change set, he assumes ownership of the work item(s) to satisfy the pre-condition. You'll still have the audit trail in the work item of who owned the work item at which time. Or you could change the requirement to own the work item and use work item approvals instead. You can prevent delivery unless the correct approvals are in place from other team members. It may slow things down but team members will be checking on each other that a work item is associated, etc. A third, and most complicated, option is to write your own pre-condition. You could customize it the way you like to fit your own process. It sounds like you would want it to check that at least one work item is owned by the deliverer. More information here. |
Geoffrey Clemm (30.1k●3●30●35)
| answered May 15 '13, 4:52 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited May 16 '13, 12:26 a.m.
In this case, you'll want to use the "Require Work Items to Match Query" deliver precondition, which gives you the option of "At least one work item must match".
|
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
Thanks Tim and Geoff for the suggestions and info.
I am wondering in the precondition [Require work items and comments]'s workitem owner constraint, if I choose optional, will that allow the configure amdin to achieve both when replacing the component from another stream:
. For those changesets already having associated workitems, the configure admin won't get the any errors complaining the owner is not configure admin because the workitem owner is optional
. And the configure admin need to associate the workitem with the changeset without association because the precondition is set?
If not, what that constraint is for?
Marking "work item owner" as "Optional" just means "do not require anything about the work item owner". So for example, if you want to require that a change set be associated with a work item, but don't care who the owner of the work item is, then you'd set the "work item owner" as "Optional".