Bug search on dependency changes misses relevant results

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
14 years ago
8 years ago

People

(Reporter: clklein, Assigned: mkanat)

Tracking

Details

(URL)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040212 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040212 Firefox/0.8

The dependson and blocked "rules" in Search.pm join the bugs table with
dependencies for all searches. This is inappropriate when searching for
dependency changes because it limits the search to bugs which are currently in
dependent relationships. For example, searching for bugs that have ever depended
on a bug n will only turn up bugs which have depended on bug n AND are currently
blocked by some bug. 

I think the solution might simply be to change these rules to
"dependson,(?!changed)" and "blocked,(?!changed)." 

Reproducible: Always
Steps to Reproduce:
and the same thing probably happens with CCs and keywords, I bet.

Do we also have a problem because those fields need to do a "contains" on the
activity table instead of "equals" since the added/removed columns can contain
more than one value? or are we already dealing with that?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 2

14 years ago
Sorry, I meant to explain that URL. I added landfill_bug 2087 as depending on
landfill_bug 666 and then removed that dep. The URL queries for
BugsThisDependsOn::changed from::666 and returns no hits.

I would not be surprised if this or similar bugs exists with other fields, but I
haven't had the time to verify this yet. 

I think you're right about the multiple-nature of the activity field, Dave.
Should  someone file a bug for this issue? 

Comment 3

14 years ago
The way we will eventually we able to do searches like the ones that you want is
as follows....
in the same chart,

actvity.field :: substring :: blocked 
AND 
activity.removed :: regexp :: (^|\D)666($|\D)

we need to simply add the activity field, who, when, added, removed as left side
items. Then, we get to use regexp, substring, etc.. to locate stuff properly

I dont think we should add those to the boolean charts until we seperate the
normal advanced search from the "super advanced" search because people will be
terrified of the UI.

We could make life a bit easier for people by recognizing the multi-selects on
any activity change and helping the user make the search(^|,)\s*whatever( ,|$)

Comment 4

14 years ago
Actually, try this...

change

        ",changedfrom" => sub {
             my $table = "act_$chartid";
             my $ftable = "fielddefs_$chartid";
             push(@supptables, "bugs_activity $table");
             push(@supptables, "fielddefs $ftable");
             push(@wherepart, "$table.bug_id = bugs.bug_id");
             push(@wherepart, "$table.fieldid = $ftable.fieldid");
             $term = "($ftable.name = '$f' AND $table.removed = $q)";

to

        ",changedfrom" => sub {
             my $table = "act_$chartid";
             my $ftable = "fielddefs_$chartid";
             push(@supptables, "bugs_activity $table");
             push(@supptables, "fielddefs $ftable");
             push(@wherepart, "$table.bug_id = bugs.bug_id");
             push(@wherepart, "$table.fieldid = $ftable.fieldid");
if ($f =~ /^(cc|dependson|blocked)$/) {
             $term = "($ftable.name = '$f' AND LOWER($table.removed) REGEXP  " .
&::SqlQuote("(^|,\s*)$v(,|$)") . ")";
} else {
             $term = "($ftable.name = '$f' AND $table.removed = $q)";
}


If that works, we should be able to extnd this to flags and keywords as well.
(Reporter)

Comment 5

14 years ago
(In reply to comment #4)
> Actually, try this...
> 
> change
> 
>         ",changedfrom" => sub {
>              my $table = "act_$chartid";
>              my $ftable = "fielddefs_$chartid";
>              push(@supptables, "bugs_activity $table");
>              push(@supptables, "fielddefs $ftable");
>              push(@wherepart, "$table.bug_id = bugs.bug_id");
>              push(@wherepart, "$table.fieldid = $ftable.fieldid");
>              $term = "($ftable.name = '$f' AND $table.removed = $q)";
> 
> to
> 
>         ",changedfrom" => sub {
>              my $table = "act_$chartid";
>              my $ftable = "fielddefs_$chartid";
>              push(@supptables, "bugs_activity $table");
>              push(@supptables, "fielddefs $ftable");
>              push(@wherepart, "$table.bug_id = bugs.bug_id");
>              push(@wherepart, "$table.fieldid = $ftable.fieldid");
> if ($f =~ /^(cc|dependson|blocked)$/) {
>              $term = "($ftable.name = '$f' AND LOWER($table.removed) REGEXP  " .
> &::SqlQuote("(^|,\s*)$v(,|$)") . ")";
> } else {
>              $term = "($ftable.name = '$f' AND $table.removed = $q)";
> }
> 
> 
> If that works, we should be able to extnd this to flags and keywords as well.
> 

I think that method would work. Another possiblity would be to store each
added/removed item in its own bugs_activity record. That table might get pretty
big, but I'm not wild about storing CSV data in a field either.
(Reporter)

Comment 6

14 years ago
I think I've discovered another problem with the ,changed rules. These search
for rows in the bugs_activity field with fieldname = $f, but $f is sometimes
modified from the field identifier used in bugs_activity to refer to another
column/table. For example, searching for QA Contact::changed_to::foo@bar.baz
hits the following rules:

^qa_contact, (qa_contact , changedto , foo@bar.baz ) =>
map_qa_contact.login_name , changedto , foo@bar.baz ,

,changedto (map_qa_contact.login_name , changedto , foo@bar.baz ) =>
map_qa_contact.login_name , changedto , foo@bar.baz , (fielddefs_0.name =
'map_qa_contact.login_name' AND act_0.added = 'foo@bar.baz')

A solution to this (and the original bug) would be to put the ,changed rules at
the top of the list, but there might be a better way.
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
(Assignee)

Comment 8

8 years ago
This should be fixed on trunk as of yesterday or so.
Assignee: query-and-buglist → mkanat
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.