240398 - Using boolean charts operators like "not equals" or "nowords" with flags does not return bugs that entirely lack flags

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, defect, P1)

Description

[Vlad Dascalu]

If you search for bugs containing "editgroups.cgi" in the summary, you get a
fairly decent list, including bug 190222:

http://bugzilla.mozilla.org/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=editgroups.cgi&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

However, if we add to that query the boolean condition: "Flag is not equal to
approval?", the result list doesn't include anymore bug 190222:

http://bugzilla.mozilla.org/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=editgroups.cgi&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=flagtypes.name&type0-0-0=notequals&value0-0-0=approval%3F

At the moment, bug 190222 doesn't have the approval flag set (but that might
change in the future).

Comment 1

[Vlad Dascalu]

We might want this for 2.18. Or not.

Comment 2

[Dave Miller [:justdave]]

The bug in question didn't have any other flags set either.  So there were no
flags on that bug that weren't equal to approval? :)  Funny how that logic
works, ain't it?

I could swear up and down this was a dupe, but I'll be damned if I can find the
original.  I know it's been discussed a lot before. :)  I think there's an INNER
JOIN (implicit with a comma perhaps) somewhere that should be a LEFT JOIN.

We've had the same problem for ages with searching for anything related to
attachments, though, so this is nothing new.  Not worth holding 2.18 for, but
I'll probably take it if it's fixed before then.

Comment 3

[Tomas Kopal]

Can't this be a dup of bug 275523? Can you re-test it?

Comment 4

[Dave Miller [:justdave]]

setting blocking2.20 to make sure this gets dealt with.  Fixing dependency so
it's the correct direction.

If this is still reproducible, I'll call it a 2.20 blocker now.  If it isn't, it
needs to get duped to bug 275523.

Comment 5

[Dave Miller [:justdave]]

Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.

Comment 6

[Joel Peshkin]

The flag code in Search.pm does still need to be fixed.  Its logic is just plain
wrong.  When we do fix it, saved queries with boolean searches on flags will break.

Comment 7

[Myk Melez [:myk] [@mykmelez]]

"If it's not a regression from 2.18 and it's not a critical problem with
something that's already landed, let's push it off." - Dave

Comment 8

[Matthew Sackman]

Against, 2.18, the funcdef for flagtypes.name pushes the wrong thing onto
@having in the m/not/ case.

It should do:
 push(@having, "(allflags_$chartid = matchingflags_$chartid or allflags_$chartid
= 0)");
but currently it does
 push(@having, "(allflags_$chartid = matchingflags_$chartid)");

Making this change allows bugs with no flags to be returned where the type
contains not.

Comment 9

[Peter Kay]

I love the current subject for this bug.

Can I ask:  This bug is about boolean searching with "not equal" (etc) not
returning bugs with no flags set at all?

Would "Boolean search for flags ignores bugs with no flags" be an appropriate
subject, or should I file a new bug?

Comment 10

[Joel Peshkin]

That would be one manifestation of this bug (so another bug would be a dupe). 
There would be many.

Essentially, now that the boolean charts work, the flags, which had their own
band-aid, need to adopt the more general solution.

Comment 11

[Joel Peshkin]

*** Bug 310281 has been marked as a duplicate of this bug. ***

Comment 12

[Frédéric Buclin]

Only security and dataloss fixes will be accepted on the 2.20 branch.

Comment 15

[Wayne Mery (:wsmwk)]

target milestone is still set at 3.0 so I'm wondering if this missed being reprioritized in the bug reviews? 

it's rather a nasty bug.  does it figure in anywhere in the 4.x time frame?

Comment 16

[Frédéric Buclin]

Yeah, that's too late for 3.0, and nobody is working on this code these days. removing the milestone.

Comment 20

[Max Kanat-Alexander]

Attachment: v1

This makes flagtypes.name work with all the boolean chart operators.

Comment 21

[Max Kanat-Alexander]

For those wondering, this is heavily dependent upon some refactoring that was done on the trunk, so it is very unlikely to be backported to 4.0.

Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/trunk/
modified Bugzilla/Search.pm
modified xt/lib/Bugzilla/Test/Search/Constants.pm
modified xt/lib/Bugzilla/Test/Search/OrTest.pm
Committed revision 7740.