When marking bugs dupes of one another, it is very easy to accidentally type in the wrong number in the dupe field. (I've done it and seen it done countless times as well). True, I should be more careful, but it would be great if instead of processing the dupe right away, would load a page asking for confirmation of the duplicate marking. This way you would see if the bug you are marking a dupe is really the bug you want. For example the page could say: You are marking this bug a duplicate of Bug 123456 When marking a duplicate of another bug, confirmation should be displayed before commit. Proceed? [ YES ] [ NO, GO BACK TO BUG 9876543 ]
Priority: -- → P2
Target Milestone: --- → Bugzilla 2.16
The basic functionality for this is implemented in my patch for bug 96085. I suppose this should probably have a user pref and an item on the parameter page associated with it since I doubt everyone wants this enabled by default. Taking bug. I'll start on this after final review of the patch on 96085.
Assignee: justdave → caillon
17 years ago
Status: NEW → ASSIGNED
Moving to new product Bugzilla...
Component: Bugzilla → User Interface
Product: Webtools → Bugzilla
Version: Bugzilla 2.13 → 2.13
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
This might go nicely with Bug 40896. Seeing a preview of any additional comments (or maybe even any changes) you've added to a bug would hopefully allow you to see if things are right in the case of marking duplicates (for example, by getting the title tip for the link to the bug you're duplicating against and making sure the summary is what you expect). Just something to consider for dependency purposes.
Sigh. No time to work on this anymore... ->Default owner.
Assignee: caillon → myk
Status: ASSIGNED → NEW
The User Interface component now belongs to Gerv. Reassigning all UNCONFIRMED and NEW (but not ASSIGNED) bugs currently owned by Myk (the previous component owner) to Gerv.
Assignee: myk → gerv
Reassigning back to Myk. That stuff about Gerv taking over the User Interface component turned out to be short-lived. Please pardon our confusion, and I'm very sorry about the spam.
Assignee: gerv → myk
Enhancements which don't currently have patches on them which are targetted at 2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. Consideration will be taken for moving items back to 2.18 on a case-by-case basis (but is unlikely for enhancements)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
It would be worth making an XMLHttpRequest to Bugzilla for the summary of the duplicate bug and displaying it next to the duplicate bug # field, but it's not worth forcing everyone to confirm duplication when users get it right most of the time and the cost of getting it wrong is minimal (simply reopening the bug and marking it duplicate again; ultimately this should just be marking it duplicate again).
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.