The reason for this bug is the necessity to have option to resolve multiple bugs by changing resolution to 'Duplicate' without getting multiple automatic entries in the reference bug. In the Mail client we have long list of originally logged separate UI issues. Later that issues were combined in the summary bug. Now we would like to get rid of the original bugs without making big 'noise' in the summary bug. So far there is manual way to mark bug as duplicate. But in this case the summary bug will have many many automatic entries with duplicate notation... We are looking for the way to avoid this. Another possibility: to use the link: 'Change several bugs at once', then to have additional option on the coming page with 'Resolve bugs, changing resolution to'. Current options don't include 'Duplicate' or 'Close', which might be useful for us.

I think this is such a once off we shouldn't support such usage. If it's a real problem you don't need mark it DUPLICATE.

So, I'm not sure /exactly/ what olga was asking for, but I /think/ it's more than a one-off need. We frequently get massive numbers of identical stack traces; being able to query on them and mark them all as duplicates in one swoop would be wonderful. Ximian and GNOME both also use 'NEEDINFO' statuses... being able to move things to there en masse would be used fairly regularly, and allow us to do a lot of good cleanup. So... maybe post-2.16 I can look at the new buglist and see how workable this would be...

It's exactly what I asked for. Yes, it would expand our options.

This feature would also come in handy when trying to untangle a mess of several seemingly related bugs in which many bugs were duped against the wrong original reports.

OK, this bug adds back-end support for change-several-bugs-at-once to be able to mark bugs as duplicate. I had a need for this at work because we had a script that was making changes to bugs based on data from another source, and it needed to be able to mark a single bug as a dupe without loading the bug form and resubmitting the entire bug data. The process works like this: - it now steps through @idlist and marks each bug as a duplicate - the original will get an additional comment for each bug marked as a dupe of it (obviously not optimum, but hey, it works :) - it sanitychecks that none of the bugs in the list match the original and that all of the bugs in the list are still open. It will ThrowUserError before any changes are made if any bug in the list is already resolved. Things this probably (I haven't tested it, but it's very likely) doesn't cope with well yet: - DuplicateUserConfirm is now called for every bug in the list (but it's done prior to any changes being made). Unfortunately, nothing is done to keep track of which bugs have been confirmed, and there's no option to "skip" a bug and do the rest. So *if* there's more than one in the list that needs to be confirmed, the first one you confirm will confirm all of them. I wasn't too worried about the above for my purposes, because we don't have security groups in the way in the place we're using it, but it probably needs to be resolved before this can be checked in.

Fixing summary... most other statuses you can already do from change-multiple, you just have to have all bugs that the status change is applicable to in the search results before it'll show you the option to do it.

this is fairly annoying, can someone please see about getting this fixed for 3.0?

This is not a blocker. We're in soft freeze, and it doesn't have a completed patch awaiting review.

Duplicate of Bug 101894 or vice-versa?

I was just working in a private Bugzilla installation that I manage and stumbled across the need to mark several issues as duplicates of a master issue. These issues come in from an auto-ticketing monitoring system that creates bugs for investigation in Bugzilla. Sometimes, several of these come in at once. I was just about to report this issue as a feature request when I stumbled upon this bug here, which seems rather long lived. Is there any headway being made with this officially, or is this something that is still in need of pick up and work?

(In reply to comment #9) > Duplicate of Bug 101894 or vice-versa? No. 101894 is about marking *one* bug as a duplicate of several others, while this one is about marking *several* bugs at once as duplicates of a single one.