Bug 21219

The --- resolution is selected by default, which means open bugs only, as expected. Bugzilla never selected any product or component by default, unless you configured it that way for your account (make the pre-selection you want, then click the "remember these as my default search options" checkbox at the bottom of the page).

That's not right.  I never once had to do any manual selections or change my defaults.  This had always been working correctly until this morning.

(In reply to Frédéric Buclin from comment #1)
> The --- resolution is selected by default, which means open bugs only, as
> expected.

Well, I hadn't expected to no longer see the matching statuses (NEW, UNCONFIRMED, ASSIGNED and REOPENED, iinm) being pre-selected, as they used to ;-)

I understand that even if nothing apart from the "---" resolution is visibly selected, that everything should work like before, so like when we could see what's preselected?

@ David Walser

Can you confirm that the invisible defaults work like the visible ones we had before?

Or was the problem you suddenly hit yesterday, that they do not?

If so, please give example search settings that fail.

CC: (none) => marja11
Assignee: sysadmin-bugs => LpSolit
Keywords: (none) => NEEDINFO

(In reply to Marja van Waes from comment #3)
> Can you confirm that the invisible defaults work like the visible ones we
> had before?

There is no "invisible defaults". Having all open bug statuses selected or having only the --- resolution selected means exactly the same thing.

Please don't set me as assignee. There is nothing broken, and there is no regression. So nothing for me to fix.

Assignee: LpSolit => sysadmin-bugs

Marja, when I tried a search with no resolutions selected, no bugs were found.  So, it most certainly is broken.

The bug was assigned to you because you made the change. Wasn't it a good reason? I'm adding you in CC because my answer is mainly addressed to you, though it's for others to consider too.

While "---" makes the URL of queries shorter, the drawback is that it is almost invisible and harder to understand at first sight. It's really not obvious that it will search for open bugs only until you go through the mental effort of thinking in an inversed way. The selection used to be positive : bugs whose status is NEW, UNCONFIRMED, ASSIGNED or REOPENED (== bugs which are open). That was plain, simple. Now it's an inversed statement (bugs which have no resolution => bugs which are open), which gives mind an extra step to grab it. The result of the queries is the same but the semantics differ.

Also, one can easily forget to de-select it while searching for all bugs, or just closed bugs (which I would naturally do by selecting or deselecting the statuses. Using resolution for that works but it's not straightforward). This is *exactly* what happend to David, I think.

But I think the main point is that the previous way worked, so there must be reason to change it to something else. Since there is no major added value to the new defaults (and at least one drawback), I'd revert to how we did before. You can call it resistance to change, and maybe it is, in part, but when introducing change usually we have to show users why the new way is better for them, and here I don't see.

Actually, which default we use is not very important to me and I think that people will still manage to use advanced search. My point is rather about this: what's the benefit of changing, considering the drawbacks? Or am I just making them out?

(In reply to Samuel Verschelde from comment #7)
> I'm adding you in CC because my answer is mainly addressed to you,
> though it's for others to consider too.

Oops, due to mid-air collision I forgot to. Done now.

CC: (none) => LpSolit

I had a look at git's history and the change has this comment: "Fix default Bugzilla queries". So I assume something was broken. What was broken?

(In reply to Samuel Verschelde from comment #9)
> I had a look at git's history and the change has this comment: "Fix default
> Bugzilla queries". So I assume something was broken. What was broken?

Nothing was broken. I updated them to match upstream instead of keeping those from old versions.

The disadvantage of pre-selecting open statuses is that it's not future proof. If one decides to rename or create a new bug status, the query will miss it. If you want all bugs, it's much easier to unselect the --- resolution only than to unselect all already selected bug statuses (or have to select all the remaining ones).

(In reply to David Walser from comment #6)
> Marja, when I tried a search with no resolutions selected, no bugs were
> found.  So, it most certainly is broken.

I don't manage to reproduce that, unless I search for "ice cream" ;-)

Please tell which search string(s) you used where, when you wrongly got 0 search results.

(In reply to Frédéric Buclin from comment #10)
> (In reply to Samuel Verschelde from comment #9)
> > I had a look at git's history and the change has this comment: "Fix default
> > Bugzilla queries". So I assume something was broken. What was broken?
> 
> Nothing was broken. I updated them to match upstream instead of keeping
> those from old versions.
> 
> The disadvantage of pre-selecting open statuses is that it's not future
> proof. If one decides to rename or create a new bug status, the query will
> miss it. 

This is a valid argument, though if someday we add, rename or remove statuses, we will still have to review all our saved searches which were made with explicit status lists. So it's a bit late :)

> If you want all bugs, it's much easier to unselect the ---
> resolution only than to unselect all already selected bug statuses (or have
> to select all the remaining ones).

Less clicks, arguably, but it's harder to guess when you don't know. If "---" would be phrased "Open bugs", then it would be clear.

(In reply to Samuel Verschelde from comment #12)
> So it's a bit late :)

It's never too late to improve things. And it makes sense now that I upgraded Bugzilla earlier this year. Else things will never improve.

Marja, when I searched for kmail with these new defaults with no statuses selected, I got no results.  The old default preselected everything but UNCONFIRMED, RESOLVED, and VERIFIED IIRC.  We should restore the previous default.  There was no other change that necessitated this one.

(In reply to David Walser from comment #14)
> Marja, when I searched for kmail with these new defaults with no statuses
> selected, I got no results.  The old default preselected everything but
> UNCONFIRMED, RESOLVED, and VERIFIED IIRC.  We should restore the previous
> default.  There was no other change that necessitated this one.

Typing "kmail" in the "Summary" field returns 7 bugs:

https://bugs.mageia.org/buglist.cgi?query_format=advanced&resolution=---&short_desc=kmail&short_desc_type=allwordssubstr

And I can't reproduce it, either.

Maybe Bugzilla had a hiccup when you tried, David, and it works better for you, now?

I'm in favour of seeing something even more explanatory than stormi suggested:

     --- (not resolved, so only open bugs)

Keywords: NEEDINFO => (none)

Nope, this is still all kinds of wrong.

Just searched for "spice".

Product: Mageia
Component: everything selected
Status: NEW, ASSIGNED, REOPENED, RESOLVED
Resolution: --

0 bugs found.

Change Resolution to select everything but MOVED and I get some results.

I can't reproduce with that exact same query: https://bugs.mageia.org/buglist.cgi?bug_status=NEW&bug_status=UNCONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&component=Backports&component=Installer&component=New%20RPM%20package%20request&component=Release%20%28media%20or%20process%29&component=RPM%20Packages&component=Security&list_id=80375&product=Mageia&query_format=advanced&resolution=---&short_desc=spice&short_desc_type=allwordssubstr

Well that's twice then that we're seeing different behavior.  That doesn't change the fact that it is what I'm seeing and these new defaults are quite broken for me.

Can you post your non-working query so that we can compare them? Regardless of the discussions on the new defaults, there seems to be a bug to investigate here.

(In reply to David Walser from comment #17)
> Product: Mageia
> Component: everything selected

Selecting everything is the same as selecting nothing.


> Status: NEW, ASSIGNED, REOPENED, RESOLVED
> Resolution: --

If you keep the resolution set to ---, then you will automatically exclude RESOLVED bugs as RESOLVED bugs have a resolution, and --- means unresolved.

(In reply to Samuel Verschelde from comment #12)
> If "---" would be phrased "Open bugs", then it would be clear.

So, whatever upstream bugzilla developers thing, it IS a fact that "---" as synonym of "all open bugs" is not straightforward and is even confusing (I got confused, David probably got confused, I think that marja told me on IRC that she was confused too). Can it be renamed to "Open bugs" to avoid any confusion?

Just searched for nettle.

Product: Mageia
Component: nothing selected (which you said should be the same as everything)
Status: NEW, ASSIGNED, REOPENED, RESOLVED
Resolution: --

No results.

Trying with spice doesn't find RESOLVED bugs.  I tried a different search this morning with similar options (don't remember what) which did find some RESOLVED bugs, but none with Security as the component even though it should have.

How did search get so screwed up?

Summary: Advanced search new default selection slightly confusing => Advanced search new default selection very confusing and broken

(In reply to David Walser from comment #23)
> Just searched for nettle.
> 
> Product: Mageia
> Component: nothing selected (which you said should be the same as everything)
> Status: NEW, ASSIGNED, REOPENED, RESOLVED
> Resolution: --
> 
> No results.

In comment 21, I said that you must unselect the "---" resolution if you want to include resolved bugs. If you keep the "---" resolution selected, then you only get open bugs (a.k.a unresolved bugs, i.e. bugs with no resolution).

With --- unselected, I can see 4 bugs:

https://bugs.mageia.org/buglist.cgi?quicksearch=ALL%20summary%3Anettle

N.B: you won't get this URL, because I used the quick search feature to get the list.

David, as you seem to be a heavy user of Bugzilla, I suggest you use the quick search feature for simple queries. It works in a very simple way and doesn't care about what defaults are for the advanced search page.

In the search field in each page header/footer, simply type:


ALL summary:nettle

to get ALL bugs with "nettle" in their summary. Or:


summary:nettle

to get only OPEN bugs with "nettle" in their summary.


If you are looking for several words in the bug summary, things are a bit more difficult. For example:

summary:"nettle 2.7"

(with quotes, because there is a whitespace) would only return open bugs with this exact string in the bug summary. But:

summary:nettle,2.7

(without quotes, but with words separated by commas, without spaces around the commas) would return open bugs with either "nettle" OR "2.7" in the bug summary. But:

summary:nettle summary:2.7

(summary: repeated once per word) would return open bugs with "nettle" AND "2.7" in the bug summary, even when the bug summary doesn't match "nettle 2.7" exactly. So for instance, it would catch "nettle with version 2.7" because both words are present in this string.

This last form is not ideal when you need to search for several words, because you have to repeat summary: several times, but this feature is there if you need it.


There are more fields and features which you can use, see the help page at https://bugs.mageia.org/page.cgi?id=quicksearch.html


Personally, I use quicksearch very often for trivial queries. For instance:

FIXED priority:release_blocker milestone:"Mageia 6"

returns all bugs marked as FIXED with priority = release_blocker and whose target milestone is Mageia 6. You can even use shortcuts for field names, as long as they match only one field. So for instance, you can type "pri:" instead of "priority:", because no other fields begins with "pri". I could give you tons of other examples, but I guess you get the point.