Closed Bug 474550 Opened 15 years ago Closed 15 years ago

Boolean query Dependency Searching: Blocks doesn't find nested blockers

Categories

(Bugzilla :: Query/Bug List, defect)

All
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: cward, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121622 Fedora/3.0.5-1.fc10 Firefox/3.0.5
Build Identifier: 3.1.3

Not sure if i have the summary right, but here's the deal. I would like to find
all the bugs which block the 3rd level (nested) Tracker bugs. Using Boolean query, I am unable to to this using the blocker/depends on fields. It seems boolean queries do not search past the top-level scope to find dependencies. 

For example, bug #000000 is a My Component Feature Request Tracker bug. I can search for all bugs which block this bug, no problem.

Bug #111111 is the All Product Compoment Features Request Tracker bug, which includes the tracker #000000 above, along with all other Component trackers for the specific Product. But if i try to search for all bugs the block 111111
(ie, all component requests), i get 0 bugs returned. 

I would expect to see the tree search completed and results returned. 

If this is not the correct manner to complete this type of search, please let
me know and feel free to close this request.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.



I was told by Dave Lawence (dkl@redhat.com) that:

...Bugzilla uses the boolean search values to create SQL and
currently the SQL only looks for direct relationships. You would need to add
special code to Bugzilla to do some recursive operations with multiple SQL
statements to drill down and look for a blocker that is multiple levels deep.
showdependency.cgi?id=XXXX does allow for exporting as XML by appending
&ctype=xml that you could use to search for a bug id but is not as automatic as
you are looking for I think.

He's right, this is not the solution i'm looking for.
I would say that the right way to do this kind of searches is to use dependency trees or dependency graphs. With dependency trees, you can then click the "View as buglist" link.
But I would like to 'change multiple bugzillas', all of which are part of the root tracker 'All Product Compoment Feature Requests'. With the tree, i'm still force to open each bugzilla up separately. With several hundred bugs, it's impractical.
(In reply to comment #2)
> But I would like to 'change multiple bugzillas', all of which are part of the
> root tracker 'All Product Compoment Feature Requests'. With the tree, i'm still
> force to open each bugzilla up separately.

  No, just do "View as buglist" on the dependency tree.

  Anyhow, I don't think we're going to implement "find all bugs in the bugzilla that block this bug, as far down the dependency tree as you want to go". That's what showdependencytree.cgi is for.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Well ****. Why wouldn't you implement it? For me, Showdependencytree.cgi doesn't do what i need it too. Unless i'm totally mistaken here...

'View as Buglist' or 'change several' from within showdependencytree.cgi only shows the buglist of trackers... not the BUGLIST of bugs. This is not what i want. I want to be able to return a list of BUGS, or whatever is at X branch, in this case, the last branch of the trackers tree. I don't care about the trackers themselves.

I would also like to be able to query these trackers in this manner using XMLRPC... and showdependecytree doesn't help there either, or would it?
Today, I had to do a search of all the open bugs of a specific project that does NOT block bug id 123 (directly or via a tree).
To solve it, I had to do a weird thing, I had to go to bug 123, see its tree and add a boolean chart to get all the bugs from that project that does not contain all the listed bugs.
I think it would be good for boolean charts have an option for searching in a full tree of depends/blocks.

I don't know the dificulty of this implementation, maybe due to a few users need, it does not worth to make it.

boolean fields:
  blocks+depends "contains below" or "contains up" or "contains both direction" a value
I'm glad someone else agrees with me on this one. I really do believe this would be a good feature to implement. Pedro, please feel free to open a new bug to make your request :-) to get it back on someone's radar. CC me if you do.
You need to log in before you can comment on or make changes to this bug.