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).

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 .)

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

moving to real milestones...

And RESOLVED FIXED should probably automatically confirm.

moving

correcting version field lost in product move

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.

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

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.

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?

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

Re-reading the comments, this sounds like bug 99251

But that bug only applies to FIXED resolutions.

"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.

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.

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

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.

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

Comments are included in the patch itself. ;)

Comment on attachment 181827 [details] [diff] [review] patch, v1 I don't think I'll review this any time soon...

(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.

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 on attachment 181827 [details] [diff] [review] patch, v1 bitrot

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

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