34172 - Bug can become unconfirmed even if it has enough votes to be confirmed by votes

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Jesse Ruderman]

Bug 32218 was incorrectly marked as "resolved fixed" and then "verified fixed", 
and when I reopened it, it had three votes.  It ended up in the "unconfirmed" 
state.  Since the bug was "unconfirmed" just before becoming "fixed", my guess 
is that bugzilla missed a "popular vote" confirmation that should have occurred 
while the bug was marked as "fixed" (but would only show up if the bug were to 
be reopened).

Comment 1

[Terry Weissman]

[e-mail] 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 .)

Comment 2

[Matthew Tuck [:CodeMachine]]

I don't think you should be able to vote for a resolved bug.

Comment 3

[Dave Miller [:justdave]]

moving to real milestones...

Comment 4

[Matthew Tuck [:CodeMachine]]

And RESOLVED FIXED should probably automatically confirm.

Comment 5

[Zach Lipton [:zach]]

moving

Comment 6

[Dave Miller [:justdave]]

correcting version field lost in product move

Comment 7

[Matthew Tuck [:CodeMachine]]

OK, I'm going to put checks in place to check this sort of thing over at bug
#97971.  Resolving FIXED automatically confirming is over at bug #99251.  Not
being able to vote for resolved bugs is #16027.

The last two would be solutions to this, or we could just properly set
everconfirmed  on resolved bugs, which might be a good idea anyway for
robustness purposes even if we implement one of those.

Comment 8

[Dave Miller [:justdave]]

no patch yet, not a blocker, we're froze for 2.16

-> 2.18

Comment 9

[Joel Peshkin]

These unloved bugs have been sitting untouched since June 2002 or longer.  If
nobody does anything else to them, they certainly won't make 2.18
Retargetting to 2.20.  If you really plan to push them right now, you might pull
them back in.

Comment 10

[alanjstr]

Is this still a problem?  How about some steps to reproduce?  What I want to
know is, how do you set a bug back to being unconfirmed?  Reopening sets the
status to reopened, no?

Comment 11

[Jesse Ruderman]

I've seen bugs reopen into the "unconfirmed" state.  I assume that happens if
you reopen a bug that was never confirmed.

Comment 12

[alanjstr]

Re-reading the comments, this sounds like bug 99251

Comment 13

[Jesse Ruderman]

But that bug only applies to FIXED resolutions.

Comment 14

[alanjstr]

"Resolving as Fixed confirms the bug".  Reopening would, in theory, not go back
to UNCO.  I'm not sure what this has to do with votes.  Either the bug gets
confirmed by votes or when resolved.

Comment 15

[Jesse Ruderman]

I imagine the steps to reproduce this bug are:
1. Resolve UNCO bug as WONTFIX.
2. Get 3 people to vote on it.
3. Reopen the bug.

Result: bug is now UNCO.

Expected: bug is now REOPENED (because of the votes).

I haven't actually tried those steps, so I don't know whether this bug still exists.

Comment 16

[Dave Miller [:justdave]]

ah, that makes sense, if the vote threshhold is reached while the bug is closed,
it probably doesn't do the confirmed check.

Comment 17

[Frédéric Buclin]

Taking! I have a patch which does a better job that what we actually have in
Bugzilla. The point is that CheckIfVotedConfirmed() in CGI.pl only checks
unconfirmed bugs:

if ($votes >= $votestoconfirm && $status eq $::unconfirmedstate) {...}

this should be:

if ($votes >= $votestoconfirm && !everconfirmed) {...}


The idea to automatically set everconfirmed = 1 to FIXED bugs is bad as any
reporter could use this way to confirm his bugs:

1. Create a new bug. This bug is unconfirmed for users without privs.
2. The reporter closes his bug as RESOLVED FIXED. The bug gets confirmed.
3. The reporter reopens his bug. The bug is now NEW because everconfirmed = 1!

So I'm against bug 99251 and I will ask justdave to wontfix it. If the bug is
valid, it should be NEW first. If this was fixed by another bug, then it is a dupe.

Comment 18

[Dave Miller [:justdave]]

will take this for 2.20 but not blocking release on it.

Comment 19

[Frédéric Buclin]

Attachment: patch, v1

Comments are included in the patch itself. ;)

Comment 20

[Marc Schumann [:Wurblzap]]

Comment on attachment 181827 [details] [diff] [review]
patch, v1

I don't think I'll review this any time soon...

Comment 21

[Jouni Heikniemi]

(In reply to comment #19)
> Comments are included in the patch itself. ;)

I agree, but it's still a horrible pain to read.


Earlier, you said:

> The point is that CheckIfVotedConfirmed() in CGI.pl only checks
> unconfirmed bugs:
> if ($votes >= $votestoconfirm && $status eq $::unconfirmedstate) {...}
> this should be:
> if ($votes >= $votestoconfirm && !everconfirmed) {...}

I agree. But the patch contains 20k on intricate logic (albeit commented one),
and I can't digest it without decent commentary on what's going on. Even the
patch isn't excessively large by itself, I might even consider splitting it if I
were you.

Comment 22

[Max Kanat-Alexander]

This is a very large change for a small benefit. It's certainly something that
will be good to have, but let's have it in 2.22.

Comment 23

[Frédéric Buclin]

Comment on attachment 181827 [details] [diff] [review]
patch, v1

bitrot

Comment 24

[Frédéric Buclin]

Attachment: patch, v2

Thanks to all the work done in blockers, the patch shrinks to a one-liner.

Comment 25

[Frédéric Buclin]

Checking in process_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v  <--  process_bug.cgi
new revision: 1.340; previous revision: 1.339
done