181396 - boolean chart query for flag equal to review+ AND flag equal to superreview+ returns bad results

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, defect)

Description

[Asa Dotzler [:asa]]

(note: bmo specific flags)

A query for
flag equal to review+ 
AND 
flag equal to superreview+
in the boolean chart should show me all of the bugs with at least one attachment
which has both review and superreview. Instead it returns no results. I think
it's  returning results for something like "a single flag with both review+ and
superreview+ flags" which can't exist.

A query for: 
flag equal to review+
new chart
flag equal to superreview+
returns bugs with an attachment which has both flags and the less desirable (for
my purposes) bugs with two attachments each having one of the two flags.

Comment 1

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

The easy solution to this is to say "flags_0.attach_id = flags_1.attach_id" when
the user queries for (flag = "review+") NEW BOOLEAN CHART (flag = "superreview+").

The problem with this solution is that there may be valid uses for the query the
way it currently works.  The change might also break queries on bug flags,
although I doubt it unless (NULL = NULL) isn't true, in which case we could
probably do something like ((flags_0.attach_id IS NULL AND flags_1.attach_ID IS
NULL) OR flags_0.attach_id = flags_1.attach_id).

A better solution would be to construct a query that works when the user says
(flag = "review+") AND (flag = "superreview+"), since the literal interpretation
of that statement is logically impossible.  At first glance, however, that looks
difficult, since our flag querying code is very bug-centric, and we need to be
attachment-centric for this code to work.

Comment 2

[Bradley Baetz (:bbaetz)]

Why can't we do whatever attachstatus did? There, asa's query would have
returned all bugs with (an attachment with a status of review+) AND (an
attachment with a status of superreview+)

We hacked 'contains' to link to the _same_ attachment, but that was a bit evil.
Theres a bug somewher eon clarifying what is, contains, etc actually means wrt
multiple stuff, like flags, ccs, etc/

Comment 3

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

We *can* do what attachment statuses did, but then we're going to have to
differentiate between bug flags and attachment flags in the boolean chart and
join the attachments table for the attachment flags.

Comment 4

[Bradley Baetz (:bbaetz)]

Welll. Remember that I can do queries which will return multiple flags. (Stuff
like substring does that). So does 'contains', but we're overloading that.

ISTM that if we have the attachments table LEFT JOIN attachments_$chartid (or
whatever teh is obsolete uses), and then knew not to do a simple inner join (so
that we dont' get duplicate tables), that would fix this, right? The 2nd part
being the hardest part to do generically, but we can probably just use a
%addedattach{$chartid} hash to hack arround this.

Comment 5

[Joel Peshkin]

Unloved bugs targetted for 2.18 but untouched since 9-15-2003 are being
retargeted to 2.20
If you plan to act on one immediately, go ahead and pull it back to 2.18.

Comment 6

[Max Kanat-Alexander]

This bug has not been touched by its owner in over six months, even though it is
targeted to 2.20, for which the freeze is 10 days away. Unsetting the target
milestone, on the assumption that nobody is actually working on it or has any
plans to soon.

If you are the owner, and you plan to work on the bug, please give it a real
target milestone. If you are the owner, and you do *not* plan to work on it,
please reassign it to [e-mail] or a .bugs component owner. If you are
*anybody*, and you get this comment, and *you* plan to work on the bug, please
reassign it to yourself if you have the ability.

Comment 7

[Frédéric Buclin]

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

Comment 8

[Bernd Kuemmerlen]

We stumbled upon the issue described in Bug 315894, and I am not 100% sure if this is the same problem as the one described in this bug here, but it's likely...

Anyway, just to bring this to attention again, a problem which considerably hinders working with more complex flag scenarios in a reasonable way is described in 

(In reply to Bug 315894 comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10)
> Gecko/20050716 Firefox/1.0.6
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10)
> Gecko/20050716 Firefox/1.0.6
> 
> If a bug has more than one flag set (i.e. UATed+, Deployed+) the following
> search does not work correctly:
> 
> "Flag" "is equal" "UAT+" And "Flag" "is not equal" "Deploy+"
> 
> Regardless of the second condition on the Flag field all bugs with "Flag" "is
> equal" "UAT+" will be returned.
> 
> I've tried different operations (i.e. contains/matches/regexp) but the reason I
> suspect in the resultset returned.
> 
> When bugs table is joined with flags table the result set will have two records
> for the same bug with two different flag values. So I suspect this causes the
> issue.
> 
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. Create two flags: UAT, Deploy
> 2. Create a few bugs and set both flags on one, only UAT+ on next, only Deploy+
> on next
> 3. Search for "Flag" "is equal" "UAT+" And "Flag" "is not equal" "Deploy+". It
> will return all bugs with UAT+ regardless of the second flag value.
> 
> Actual Results:  
> Search returns all bugs with UAT+ regardless of the second flag value.
> 
> Expected Results:  
> Search should return only bugs with UAT+ flag set and Deploy flag not set.

This functionality is crucial for some of the workflows that can be mapped with Flags (Reviews, Deployment of features etc)

Comment 9

[Max Kanat-Alexander]

The blocker should make this work, although perhaps not exactly the way you wanted in the first comment (one attachment with both flags). However, the search will find bugs that have at least one "review+" and at least one "superreview+" now.

As far as the specific behavior you wanted, I agree that that is useful and important behavior, and it will come along as a later part of the Custom Search redesign that I am engaged in right now.