Bug 480577

Summary:	Boolean query Dependency Searching: Blocks doesn't find nested blockers
Product:	[Community] Bugzilla	Reporter:	Chris Ward <cward>
Component:	Query/Bug List	Assignee:	PnT DevOps Devs <hss-ied-bugs>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	low
Version:	devel	CC:	andriusb, dkl, jconnor
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-03-09 15:28:52 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	450098

Description Chris Ward 2009-01-19 08:40:22 UTC

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 16:54:11 UTC

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 09:39:11 UTC

Posted upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=474550

Comment 3 Chris Ward 2009-01-28 08:15:03 UTC

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 17:53:11 UTC

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 06:49:58 UTC

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 07:22:00 UTC

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 15:23:46 UTC

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 15:28:52 UTC

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-10 00:45:44 UTC

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