Bug 76020 - resolved/closed dichotomy is back
resolved/closed dichotomy is back
Product: Bugzilla
Classification: Community
Component: Bugzilla General (Show other bugs)
i386 Linux
medium Severity medium (vote)
: ---
: ---
Assigned To: David Lawrence
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-10-15 17:15 EDT by Bill Nottingham
Modified: 2014-03-16 22:31 EDT (History)
2 users (show)

See Also:
Fixed In Version: 2.18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-01 16:53:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2002-10-15 17:15:58 EDT
In our current bugzilla, there is only closed, not both 'resolved' and 'closed'.
Comment 1 David Lawrence 2002-10-16 15:40:15 EDT
Fixed the behaviour to close a bug when resolving instead of RESOLVED. As for
RESOLVED being in the list of status to query against from query.cgi, this has
been like this for some time. Not a regression.
Comment 2 Aleksey Nogin 2002-12-13 15:00:43 EST
There are currently 720 bugs with status "RESOLVED".

Also, marking as a duplicate uses "RESOLVED DUPLICATE", not "CLOSED DUPLICATE".
Comment 3 Aleksey Nogin 2002-12-13 15:04:50 EST
P.S. Should all the bugs that existed prior to Bugzilla upgrade be changed to
"everconfirmed=1"? Otherwise we'll have these weird occurrences of "UNCONFIRMED"
status in reopened bugs, bugmail showing "everconfirmed" changing from 0 to 1
(for no good reason), etc.

Note You need to log in before you can comment on or make changes to this bug.