Why Merge requires a new workitem association?
Precondition is set to require work item and comments when delivering.
There are two versions of changesets which were associated with workitems by two developers.
Now the admin try to merge them and it complains there is no workitems associated for the merged changeset.
Does the tool consider the merged changeset as a new one without a workitem association even though both of them were associated with the WIs before merge?
One answer
as far as I can tell, the original change sets are completed and can no longer be modified. Therefore it is necessary to create a new change set to merge. The tool can not, or does no, predict that the work item(s) linked to the old change sets should be pushed up. And in fact it would also be reasonable to have a new work item created for this integration, owned by the person merging.
Comments
Thanks Ralph.
It makes sense to have a new changeset for the merge in which the admin(who does merge) can associate own workitem. The confusing part is that Not only workitem association message prompt in the advisor view, also there is error complaining the admin should own the workitem(two errors), this one is from the changeset with the workitem associated, because the owner is the developer, the admin has to change the owner of WI to his own. Does that mean the WI owner needs to be set as Optional? If that's the case, the precondition's work item owner setting for "is required" (2nd option and it is default) does not make sense. If it is set as "is required", I would expect owner must be set but it does not matter who is the owner. however, the test result shows both "is required" and " must be current owner(3rd option) will prompt the error that " you must own the workitem", I can see the difference between and 2nd and 3rd option in this case.
Don,
you have configured the precondition in this way. You have the following options.
- Remove the quality requirements in the precondition and make them optional
- Assign the work item save preconditions in a different way for a role that the integrator has as primary and the developers have not, see https://jazz.net/library/article/29 . Essentially this is like 1. but treats different roles differently.
The second approach changes the requirements for the special role of the integrator.