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. |
2 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Sep 15 '11, 10:15 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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: In |
|
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. |
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.