Defect #5586
openClosing when marked as duplicate (also: closing model in general)
0%
Description
In most other tracking software, marking a bug as a duplicate closes that bug. More precisely, you can close an issue and cite a reason, and the reason may be that it's a duplicate of something else.
That, to me, makes a lot more sense than what Redmine offers. In Redmine, leaving duplicates open causes all these duplicates to remain in the default issues view, cluttering up the view. Thus we have to additionally remember to close each issue when marking as duplicate.
Also, more generally speaking, would these "reasons for closing" models make more sense? E.g., I should be able to Close a bug with the reason of Reject or Fixed.
Updated by Ewan Makepeace about 14 years ago
+2
I just got bitten by this new feature - I marked 2 new bug reports as duplicates of a task in progress and closed them, only to find that the main task in progress had been automatically closed without my knowledge. Since this was a serious new bug being reported that was far from the behaviour I wanted!
The only reason I mark issues as duplicates is so that I can safely close them without offending the author, who can rest secure, knowing his problem is being worked on elsewhere. If the issues get closed together then this feature is not just not useful but dangerous and will be avoided?
Question: Is there a difference in behavior between 'duplicates' and 'duplicated by'? I never understood the distinction because duplicates implies a certain symmetry where there is no direction (unlike blocks and blocked by for example).
Updated by Woody Thrower about 13 years ago
I agree that Redmine's handling of duplicates is less than ideal (to put it mildly).
The behavior of duplicate issues is non-obvious. As I understand it, it works as follows.- Someone enters issue A.
- Someone else enters issue B.
- Another person marks issue B as "Duplicates A".
- If someone closes issue A, Redmine will close issue B automatically.
- If someone closes issue B, Redmine will leave issue A unchanged.
- Both issues can be separately prioritized, estimated, assigned, associated with different target versions, etc.
So, given the current implementation, the superset/most-complete issue should be considered "primary" (and "duplicated by" the other), and users should only update the primary issue, etc.
It could be argued that this is a training issue, that it is working by design, that stupid people shouldn't use software, that it's not a problem once you learn how it works, etc... but I prefer to see this as a usability issue that needs to be addressed. :)
I would like it if Redmine did the following when an issue was marked as a duplicate.- Relate the issue to the issue that it is said to duplicate (as it currently does).
- Consider the duplicate issue closed (by setting the status to a reserved "Duplicate" status, or whatever.
With that approach, it would be much more difficult than it is now to overlook the fact that the duplicate issue had been closed.