Default Bugzilla search does not show resolved bugs

[Ken Sharp]

From http://bugs.winehq.org/show_bug.cgi?id=18790

"The default search (the search box at the top of this page) does not 
include
closed bugs (rightly so), but it also does not include resolved bugs.  This
leads to duplicates that could be avoided."

"This is for admin to configure in Administration->Parameters->Query
Defaults->defaultquery. Add to the front of it:

bug_status=RESOLVED&"

Anyone with admin access that can make this change?

Thanks,
Ken.

[Juan Lang]

Hi Ken,
> "The default search (the search box at the top of this page) does not
> include closed bugs (rightly so), but it also does not include resolved bugs.
>  This leads to duplicates that could be avoided."

Avoiding duplicates is a good idea, but I'm not sure this will help.
The usual scenario is that a bug is first marked RESOLVED FIXED, then
CLOSED.  So changing the query would only find those bugs that haven't
yet been marked as CLOSED.  This might be helpful for the bug triagers
to remind them to close them, but won't be likely to reduce
duplicates.
--Juan

[Austin English]

On Wed, Jun 10, 2009 at 10:29 AM, Juan Lang<juan.lang(a)gmail.com> wrote:
> Hi Ken,
> > "The default search (the search box at the top of this page) does not
> > include closed bugs (rightly so), but it also does not include resolved bugs.
> >  This leads to duplicates that could be avoided."
>
> Avoiding duplicates is a good idea, but I'm not sure this will help.
> The usual scenario is that a bug is first marked RESOLVED FIXED, then
> CLOSED.  So changing the query would only find those bugs that haven't
> yet been marked as CLOSED.  This might be helpful for the bug triagers
> to remind them to close them, but won't be likely to reduce
> duplicates.

We don't close bugs that have been fixed until the next release (by
AJ). While this won't help for bugs marked RESOLVED INVALID or
RESOLVED WONTFIX, the case where it should help is for bugs that are
fixed in a git release, but that have several duplicates filed before
the next binary release. This is often the case for regressions put in
the day of/before a binary release, which gets fixed early in the next
release cycle.

-- 
-Austin