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).
We might want this for 2.18. Or not.
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.
Depends on: 171553
Flags: blocking2.18? → blocking2.18-
Can't this be a dup of bug 275523? Can you re-test it?
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.
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.
Assignee: justdave → query-and-buglist
QA Contact: mattyt-bugzilla → default-qa
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.
"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
Severity: blocker → major
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.
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?
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.
*** Bug 310281 has been marked as a duplicate of this bug. ***
Only security and dataloss fixes will be accepted on the 2.20 branch.
Severity: major → normal
Whiteboard: [wanted for 2.20]
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
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?
Yeah, that's too late for 3.0, and nobody is working on this code these days. removing the milestone.
Target Milestone: Bugzilla 3.0 → ---
Summary: Boolean flag-based query screwed → Using boolean charts operators like "not equals" or "nowords" with flags does not return bugs that entirely lack flags
Target Milestone: Bugzilla 4.0 → Bugzilla 4.2
Assignee: query-and-buglist → mkanat
Status: NEW → ASSIGNED
Created attachment 516696 [details] [diff] [review] v1 This makes flagtypes.name work with all the boolean chart operators.
Attachment #516696 - Flags: review+
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.