Bug 480577 - Boolean query Dependency Searching: Blocks doesn't find nested blockers
Boolean query Dependency Searching: Blocks doesn't find nested blockers
Status: CLOSED WONTFIX
Product: Bugzilla
Classification: Community
Component: Query/Bug List (Show other bugs)
devel
All Linux
low Severity medium (vote)
: ---
: ---
Assigned To: PnT DevOps Devs
: FutureFeature
: 147589 (view as bug list)
Depends On:
Blocks: 450098
  Show dependency treegraph
 
Reported: 2009-01-19 03:40 EST by Chris Ward
Modified: 2013-06-23 22:15 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-09 10:28:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Ward 2009-01-19 03:40:22 EST
Description of problem:
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) All Partner Feature Request Tracker bug. 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 #452016 is the Intel Feature Request Tracker bug. I can search for all bugs which block this bug, no problem.

Bug #475561 is the All Partner Request Tracker bug, which includes Intel's tracker #452016 above. But if i try to search for all bugs the block 475561 (ie, all partner requests, intel's and all others), 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.
Comment 1 David Lawrence 2009-01-19 11:54:11 EST
Yes, this would probably be best reported upstream in case we do not have time to look at it. But 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.

Dave
Comment 2 Chris Ward 2009-01-21 04:39:11 EST
Posted upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=474550
Comment 3 Chris Ward 2009-01-28 03:15:03 EST
Unfortunately, upstream has closed this request. So unless we're willing to do it in-house... or someone else can make the argument better than I... this bug needs to be closed.
Comment 4 David Lawrence 2009-01-28 12:53:11 EST
Chris, they may have a point here. For example if you go the bug 452016 Intel tracker which is the root of the dependency tree, it will give a "View as buglist" link at the top which includes *all* of the bugs listed in the dependency tree as deep as it goes. So you can do a mass edit on that buglist which will allow changes to all bugs in a dependency tree. The "view as buglist" link is not just the top level direct relationships but all bug ids tied to the tracker bug.

This seems like it will accomplish what you are trying to do.

Dave
Comment 5 Chris Ward 2009-01-29 01:49:58 EST
Close, but no cigar. I'm still only seeing the intel tree in this case blown up. I'd be useful to be able to see all the limbs in the tree standing from the top-level of the dependency tree. But i'll make this work for the time being. Luckily we don't have too many partners still :-)
Comment 6 Chris Ward 2009-01-29 02:22:00 EST
Take the Partner5.4 tracker as the example here.

https://bugzilla.redhat.com/showdependencytree.cgi?id=475561&hide_resolved=1

It'd be useful if this page blew up completely, the same way the example you mention does.
Comment 7 Andrius Benokraitis 2010-03-09 10:23:46 EST
I would assume since we in EPM are now using the cf_partner field this issue isn't a high priority anymore.
Comment 8 Chris Ward 2010-03-09 10:28:52 EST
yea; we can close this for now. if we find it's necessary we can take a second look.
Comment 9 Simon Green 2012-05-09 20:45:44 EDT
*** Bug 147589 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.