Restrict associating to closed work items but allow merges?
In this forum post, Jean-Michel stated that "the scenario we wanted to support involved the developer marking the work items as done, but not reviewed, and then adding reviewers to review and change the state to closed/reviewed. You can further control who can re-open a work item using perimssions".
After implementing the above scenario a user will get to the state where they have checked in (and probably completed) their change sets, had them reviewed, putting the work item into a 'closed' state. All is good and they are ready to deliver their changes. The problem is that if someone else has changed the same file in the meantime a 'merge' change set is created.
If the user didn't complete their change set the merges automatically get 'bundled' with the user's other changes and there is no problem. If the user did (as they usually do) complete their change set, the merges go into a new change set and we have a problem. The user's changes cannot be delivered without the merges, but you cannot associate the merges with the work item due to the 'restrict associating to closed work items' rule.
Is there a way to add an exception to the 'restrict associating to closed work items' rule for merges? This would allow the scenario that Jean-Michel spoke of to be deployed.
After implementing the above scenario a user will get to the state where they have checked in (and probably completed) their change sets, had them reviewed, putting the work item into a 'closed' state. All is good and they are ready to deliver their changes. The problem is that if someone else has changed the same file in the meantime a 'merge' change set is created.
If the user didn't complete their change set the merges automatically get 'bundled' with the user's other changes and there is no problem. If the user did (as they usually do) complete their change set, the merges go into a new change set and we have a problem. The user's changes cannot be delivered without the merges, but you cannot associate the merges with the work item due to the 'restrict associating to closed work items' rule.
Is there a way to add an exception to the 'restrict associating to closed work items' rule for merges? This would allow the scenario that Jean-Michel spoke of to be deployed.
2 answers
There definitely is a bug (or at least "missing feature") here ...
namely, that you cannot prevent someone from checking in new changes to
a closed work item. I've submitted work item 177378 ("You should be
able to prevent a checkin to a change set in closed work items").
Please feel free to add a comment to indicate your interest/support.
As for giving special permission to a "merge" ... there's no way to make
that safe. All you would need to do to subvert the review process
would be to create an artificial conflict, make whatever changes you
wanted as part of the "merge" process, and then checkin your results.
Effectively, if a merge requires a change to the code, then you are not
submitting the reviewed code, so a new review is required (but if the
merge is done in a separate change-set, which is what I always
recommend, then the re-reviewer can focus on just the merge-related
changes).
Cheers,
Geoff
On 9/15/2011 9:53 AM, czardis wrote:
namely, that you cannot prevent someone from checking in new changes to
a closed work item. I've submitted work item 177378 ("You should be
able to prevent a checkin to a change set in closed work items").
Please feel free to add a comment to indicate your interest/support.
As for giving special permission to a "merge" ... there's no way to make
that safe. All you would need to do to subvert the review process
would be to create an artificial conflict, make whatever changes you
wanted as part of the "merge" process, and then checkin your results.
Effectively, if a merge requires a change to the code, then you are not
submitting the reviewed code, so a new review is required (but if the
merge is done in a separate change-set, which is what I always
recommend, then the re-reviewer can focus on just the merge-related
changes).
Cheers,
Geoff
On 9/15/2011 9:53 AM, czardis wrote:
In
this
forum post, Jean-Michel stated that "the scenario we wanted
to support involved the developer marking the work items as done, but
not reviewed, and then adding reviewers to review and change the
state to closed/reviewed. You can further control who can re-open a
work item using perimssions".
After implementing the above scenario a user will get to the state
where they have checked in (and probably completed) their change
sets, had them reviewed, putting the work item into a 'closed' state.
All is good and they are ready to deliver their changes. The problem
is that if someone else has changed the same file in the meantime a
'merge' change set is created.
If the user didn't complete their change set the merges automatically
get 'bundled' with the user's other changes and there is no problem.
If the user did (as they usually do) complete their change set, the
merges go into a new change set and we have a problem. The user's
changes cannot be delivered without the merges, but you cannot
associate the merges with the work item due to the 'restrict
associating to closed work items' rule.
Is there a way to add an exception to the 'restrict associating to
closed work items' rule for merges? This would allow the scenario
that Jean-Michel spoke of to be deployed.
I'm okay with being able to deliver once the item is in 'closed' state as that's the model we're using to prevent changes being added once the item is up for review ('Ready for Review' is in itself a closed state), although I appreciate your requirement.
Indeed you are correct that there's no way to make it safe - you would just have to trust your developers not to be malicious in their merging. It would, however, be more explicitly enclosed than allowing them to go back to a state where they are able to attach any change set that they wish.
Indeed you are correct that there's no way to make it safe - you would just have to trust your developers not to be malicious in their merging. It would, however, be more explicitly enclosed than allowing them to go back to a state where they are able to attach any change set that they wish.