Closed
Bug 7873
Opened 25 years ago
Closed 23 years ago
duplicate isn't always resolved DUP when marking as such
Categories
(Bugzilla :: Bugzilla-General, defect, P2)
Bugzilla
Bugzilla-General
Tracking
()
RESOLVED
FIXED
Bugzilla 2.12
People
(Reporter: ian, Assigned: justdave)
References
Details
Attachments
(1 file)
I submitted a change to a bug without changing anything (just put in a number in the dup field, didn't change the radio button [javascript is disabled here] and hit submit), then I clicked BACK, checked the radiobutton and resubmitted it. As expected, it detected a clash. This is normal. Unfortunately, it did so _after_ adding the notation to the other bug (bug 7516, if that matters). When I then clicked "submit the changes anyway", it told me "unknown action 7835". I don't want to try to reproduce it, we never know how far reaching the bug could be, and I don't want to mess up bugzilla.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Priority: P3 → P2
Comment 2•24 years ago
|
||
tara@tequilarista.org is the new owner of Bugzilla and Bonsai. (For details, see my posting in netscape.public.mozilla.webtools, news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara
Status: ASSIGNED → NEW
Comment 3•24 years ago
|
||
*mutter**grumble*I don't *want* to have to specify a comment for a reassignment....
Assignee: tara → donm
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 4•24 years ago
|
||
I think the solution is to prevent overriding the previous action in a midair collision. I've never heard of any other system doing it. I don't like the idea that someone can undo my action anyway. Bug #31117 asks to allow applying both changes, if possible, which could replace the lost functionality in part. Though another possibility would be to have the duplicate message be one record rather than one on each bug report, and do something tricky.
QA Contact: matty
Reporter | ||
Comment 5•24 years ago
|
||
Um, the solution AFAICT is simply to add the notation to the other bug _after_ checking that the bug being changed has not been touched. It's not complicated or anything... The problem is that this code in process_bug.cgi: 508 AppendComment($num, $::FORM{'who'}, "*** Bug $::FORM{'id'} has been marked as a duplicate of this bug. ***"); 509 if ( Param('strictvaluechecks') ) { 510 CheckFormFieldDefined(\%::FORM,'comment'); 511 } 512 $::FORM{'comment'} .= "\n\n*** This bug has been marked as a duplicate of $num ***"; 513 514 print "<TABLE BORDER=1><TD><H2>Notation added to bug $num</H2>\n"; 515 system("./processmail $num $::FORM{'who'}"); 516 print "<TD><A HREF=\"show_bug.cgi?id=$num\">Go To BUG# $num</A></TABLE>\n"; ...happens before this code (same module): 647 if (defined $::FORM{'delta_ts'} && $::FORM{'delta_ts'} ne $delta_ts) { 648 print " 649 <H1>Mid-air collision detected!</H1> 650 Someone else has made changes to this bug at the same time you were trying to. 651 The changes made were: 652 <p> 653 "; I'm not exactly sure how this should be fixed, but the easiest way of doing it would be to set a flag in the "SET DUPLICATE" handling code (first snippet quoted above) and only actually do the work after the clash detection (second snippet quoted above). See http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/process_bug.cgi
Comment 6•24 years ago
|
||
I see what you mean upon rereading. What I was talking about above was preventing the problem where a midair collision occurs and the second person overrides the first's dupe resolve, but leaves the other bug's notation.
Assignee | ||
Comment 9•24 years ago
|
||
updating the summary to more accurately reflect the direction this bug is going (and making it more general, since the problem seems to be more widespread than just mid-air collisions)
Summary: mid air collision and duplicates → duplicate isn't always resolved duplicate when marking as such
Comment 10•24 years ago
|
||
From bug 32950, "Bugzilla DUPL messages appears on DUP-to bug, but not on DUP-of bug", essentially the same problem can happen if the user attempting to mark one bug as a DUP of another lacks any of the relevant privileges or is not logged in at that time. Neither check is being made until a comment has been added to the DUP-to bug. An extension of Ian's quasi-patch to also make the checks for logged-in status and privileges before making *any* modifications should fix these problems too.
Summary: duplicate isn't always resolved duplicate when marking as such → duplicate isn't always resolved DUP when marking as such
Comment 11•24 years ago
|
||
*** Bug 58941 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Whiteboard: 2.14
Comment 12•24 years ago
|
||
*** Bug 43018 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Whiteboard: 2.14 → 2.16
Assignee | ||
Comment 13•24 years ago
|
||
moving to real milestones...
Target Milestone: --- → Bugzilla 2.16
Assignee | ||
Comment 14•23 years ago
|
||
This just became a critical severity and a 2.12 blocker. Now that we have the duplicates stored in a table, the duplicate table is aparently getting updated at the same time the marking is put on the other bug, and if that person didn't have privs for it, the duplicate bug doesn't get closed, and now no one else can do it either because it's already in the dupes table and it won't let you re-dupe it.
Severity: minor → critical
Whiteboard: 2.16
Target Milestone: Bugzilla 2.16 → Bugzilla 2.12
Assignee | ||
Comment 16•23 years ago
|
||
Assignee | ||
Comment 17•23 years ago
|
||
r= endico@mozilla.org Checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 18•23 years ago
|
||
Good catch, people - apologies that I wasn't around to fight the fire here. Gerv
Assignee | ||
Comment 19•23 years ago
|
||
Moving closed bugs to Bugzilla product
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•