Last Comment Bug 103866 - query on bugs not depending on un-fixed bugs
: query on bugs not depending on un-fixed bugs
Status: NEW
:
Product: Bugzilla
Classification: Server Software
Component: Query/Bug List (show other bugs)
: 2.15
: All All
: P3 enhancement with 5 votes (vote)
: ---
Assigned To: Ratmir Karabut
: default-qa
:
Mentors:
: 158952 168803 252461 332544 349750 823562 (view as bug list)
Depends on:
Blocks: 16743
  Show dependency treegraph
 
Reported: 2001-10-09 10:37 PDT by Adam Hauner
Modified: 2016-01-03 21:15 PST (History)
18 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
bugzilla-4.5.6-blocked.patch (3.82 KB, patch)
2014-12-07 07:03 PST, Fedor Ezeev
no flags Details | Diff | Splinter Review
Adding the blocked_somewhere field without any UI changes and corresponding helpers (2.20 KB, patch)
2014-12-08 13:29 PST, Ratmir Karabut
rkarabut: review? (justdave)
Details | Diff | Splinter Review
103866-2.patch (2.21 KB, patch)
2014-12-28 22:19 PST, Fedor Ezeev
no flags Details | Diff | Splinter Review

Description Adam Hauner 2001-10-09 10:37:38 PDT
I wanna have way to filter bug list for bugs, which depends only on
resolved/verified/closed bugs or which doesn't depend on any bug (by other
words: on bugs not blocked by dependencies). 

Inverted query is also useful.
Comment 1 Matthew Tuck [:CodeMachine] 2001-11-09 23:56:41 PST
This is kind of bug #8527, except statuses should be customisable (bug #101179),
and moving to ASLEEP might not be automatic.
Comment 2 Brant Gurganus 2002-10-13 11:31:36 PDT
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Comment 3 Stewart Gordon 2003-07-23 11:07:46 PDT
*** Bug 158952 has been marked as a duplicate of this bug. ***
Comment 4 Stewart Gordon 2003-07-23 11:30:28 PDT
*** Bug 168803 has been marked as a duplicate of this bug. ***
Comment 5 Dave Miller [:justdave] (justdave@bugzilla.org) 2004-09-18 18:16:13 PDT
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.
Comment 6 Marc Schumann [:Wurblzap] 2005-03-07 09:08:18 PST
*** Bug 252461 has been marked as a duplicate of this bug. ***
Comment 7 Frédéric Buclin 2005-11-17 07:10:49 PST
The trunk is now frozen to prepare Bugzilla 2.22. Only bug fixes are accepted, no enhancement bugs. As this bug has a pretty low activity (especially from the assignee), it's retargetted to ---. If you want to work on it and you think you can have it fixed for 2.24, please retarget it accordingly (to 2.24).
Comment 8 Bishop Clark (LC957) 2007-01-22 01:29:13 PST
*** Bug 349750 has been marked as a duplicate of this bug. ***
Comment 9 Bishop Clark (LC957) 2007-01-22 01:36:51 PST
I hacked up a mod to my own 2.22, one without a UI yet.  FYI, the hack is in attachment 249426 [details] [diff] [review], and a good idea for the UI may be obtained from attachment 233044 [details] [diff] [review] .  Works well for me, and well enough so that I can use a given dep tree for a particular ticket to plan my work.  Sorry for the spam.
Comment 10 Marc Schumann [:Wurblzap] 2007-02-12 13:42:29 PST
See also bug 185041.
Comment 11 Marc Schumann [:Wurblzap] 2007-08-20 23:09:09 PDT
See also bug 102048.
Comment 12 Frédéric Buclin 2007-11-12 07:47:52 PST
*** Bug 332544 has been marked as a duplicate of this bug. ***
Comment 13 Frédéric Buclin 2012-12-20 10:27:02 PST
*** Bug 823562 has been marked as a duplicate of this bug. ***
Comment 14 Fedor Ezeev 2014-11-30 10:45:19 PST
SQL query, returning ids of bugs, DEPENDING on non-fixed bugs, looks like this:

select blocked from dependencies join bugs on (dependencies.dependson = bugs.bug_id) where resolution = '' group by blocked;

so if we want to query on bugs, NOT depending on non-fixed bugs, we should add to the WHERE clause something like this:

WHERE ... AND bug_id not in (select blocked from dependencies join bugs on (dependencies.dependson = bugs.bug_id) where resolution = '' group by blocked) ...

I have to point, that we need to check, if a bug id is not in this list. We cannot revert any of other logical condition in order to eliminate subquery, because of bugs, not depending on other bugs at all. So its ids are not in 'dependencies' table at all.

Unfortunately, my perl experience is not good enough to write a whole patch to resolve this bug, but if this (tested and actually worked on my bugzilla installation) sql query will be helpful to someone with more strong perl skills than mine - it will be fine.
Comment 15 Fedor Ezeev 2014-12-07 07:03:59 PST
Created attachment 8532912 [details] [diff] [review]
bugzilla-4.5.6-blocked.patch

Proposed patch
Comment 16 Gervase Markham [:gerv] 2014-12-07 07:55:12 PST
Hi Fedor,

Thanks for the patch! I think the question here is whether this ability is widely useful enough to justify the added complexity in the search UI. So we may have to have a discussion about that first.

glob: what's your view?

Gerv
Comment 17 Ratmir Karabut 2014-12-08 13:09:17 PST
(In reply to Gervase Markham [:gerv] from comment #16)
> Hi Fedor,
> 
> Thanks for the patch! I think the question here is whether this ability is
> widely useful enough to justify the added complexity in the search UI. So we
> may have to have a discussion about that first.
> 
> glob: what's your view?
> 
> Gerv

Hello there,

Actual author of the patch here. Frankly, I feel the same way about UI changes and I think it could be done in a way better corresponding with overall interface structure (I couldn't find a reasonable template for radio buttons while I was working on this, and I kinda like radio buttons). Also, the way it's done now there's a minor oversight with radio not responding to the request params. Feel free to make suggestions, I will try to address them this week. Maybe a single-choice select next to the Resolution box would do?
Comment 18 Ratmir Karabut 2014-12-08 13:17:00 PST
And yeah, we could of course just dispose of the search template changes entirely. I don't think they are really needed that often, people who gonna use this feature could just use the custom search.
Comment 19 Ratmir Karabut 2014-12-08 13:29:38 PST
Created attachment 8533334 [details] [diff] [review]
Adding the blocked_somewhere field without any UI changes and corresponding helpers

Adding the blocked_somewhere field without any UI changes and corresponding helpers. The field could be used in custom search by people who actually need this.
Comment 20 Gervase Markham [:gerv] 2014-12-10 08:46:38 PST
Comment on attachment 8533334 [details] [diff] [review]
Adding the blocked_somewhere field without any UI changes and corresponding helpers

Again, thanks for the patch :-) But I'm not the right person to review this. I don't know this code well. Also, I don't know if SQL subselects are supported across all our DBs, and whether you have to use special $dbh calls for them.

I'm not sure about "Blocked Somewhere" - it isn't immediately clear to me what that means.

LpSolit might know the right things to review this...

Gerv
Comment 21 Frédéric Buclin 2014-12-10 10:03:11 PST
Comment on attachment 8533334 [details] [diff] [review]
Adding the blocked_somewhere field without any UI changes and corresponding helpers

I will let glob review this, but I really don't like 'Blocked Somewhere'. This means nothing to me. 'Depends on an open bug' or something similar would be clearer IMHO.
Comment 22 Ratmir Karabut 2014-12-10 11:16:17 PST
(In reply to Frédéric Buclin from comment #21)
> Comment on attachment 8533334 [details] [diff] [review]
> Adding the blocked_somewhere field without any UI changes and corresponding
> helpers
> 
> I will let glob review this, but I really don't like 'Blocked Somewhere'.
> This means nothing to me. 'Depends on an open bug' or something similar
> would be clearer IMHO.

Sure. I'm not too keen on it myself, that's just a name I slapped on it in working phase. But 'depends on an open bug' doesn't really tell what it does clearly enough too, I guess, because it doesn't directly imply a nested dependency. Any ideas?
Comment 23 Ratmir Karabut 2014-12-10 11:46:56 PST
(In reply to Gervase Markham [:gerv] from comment #20)
> Comment on attachment 8533334 [details] [diff] [review]

> I don't know this code well. Also, I don't know if SQL subselects are
> supported across all our DBs, and whether you have to use special $dbh calls
> for them.

Well, I have to assume they are, because there's a similar CASE for percentage_complete right above mine.
Comment 24 Fedor Ezeev 2014-12-28 22:19:50 PST
Created attachment 8542004 [details] [diff] [review]
103866-2.patch

New custom search field will be used mainly with "is empty" and "is not empty" logical operators.
So I suggest an "Unresolved dependencies list" as a name, for a whole phrases "Unresolved dependencies list is empty" and "Unresolved dependencies list is not empty" with an obvious meaning.

Do we need to rename all internal stuff in patch accordingly? Subs and Vars I mean. If yes, I will do.
Comment 25 Byron Jones ‹:glob› [PTO until 2016-10-10] 2015-01-06 23:10:27 PST
Comment on attachment 8542004 [details] [diff] [review]
103866-2.patch

fedor, thanks for this patch, however to avoid confusion it's probably better if ratmir continued to work on this patch and provide required updates.

i hope to be able to review ratmir's patch soon.
Comment 26 Ratmir Karabut 2015-01-07 03:25:19 PST
Hi, just checking in; I'm waiting for the review and suggestions on proper naming.
Comment 27 Fedor Ezeev 2015-02-02 19:50:51 PST
(In reply to Byron Jones ‹:glob› from comment #25)
> fedor, thanks for this patch, however to avoid confusion it's probably
> better if ratmir continued to work on this patch and provide required
> updates.

To avoid confusion: I'm the person, who personally interested in resolving this bug.
Ratmir are the person with good perl skills, who wrote this patch for me, on my order.

Now my perl skills are good enough to make all patch polishing in order to satisfy any code maintainer and finally to commit this function. So may be it's probably better if my patches will be reviewed too?

> i hope to be able to review ratmir's patch soon.

I hope too ))

And again. If I can do anything for speeding up a successfull patch commiting - just say, I will do :)
Comment 28 Byron Jones ‹:glob› [PTO until 2016-10-10] 2015-02-03 21:31:28 PST
ratmir, are you ok with fedor taking over this bug?
Comment 29 Ratmir Karabut 2015-02-04 13:18:06 PST
(In reply to Byron Jones ‹:glob› from comment #28)
> ratmir, are you ok with fedor taking over this bug?

Sure, though I fail to see any particular reason for that. I'm around
Comment 30 Fedor Ezeev 2015-03-22 14:20:12 PDT
So, we have a 3 month old patch for 14 years old bug, that works perfectly well in my bugzilla installation.
We have one good developer and another one not so good. They are ready to work on this bug, if this patch makes any questions.
And I have absolutely no ideas what can I do to help this bug comes to FIXED state.
Byron, please, tell me directly, what are we waiting for right now?
Comment 31 Byron Jones ‹:glob› [PTO until 2016-10-10] 2015-03-22 21:27:48 PDT
(In reply to Fedor Ezeev from comment #30)
> Byron, please, tell me directly, what are we waiting for right now?

for me to find the time to review this.

this isn't a high priority bug and reviewing changes to search generally take a while so i need to put aside a reasonable chunk of my day.  just because something works for you doesn't mean it'll work on all our supported databases and version, nor does it mean that it's the most efficient sql query (meaning on large sites it may be unreasonably slow).

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