103866 - query on bugs not depending on un-fixed bugs

Status: NEW

(Bugzilla :: Query/Bug List, enhancement, P3)

Description

[Adam Hauner]

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]]

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]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.

Comment 3

[Stewart Gordon]

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

Comment 4

[Stewart Gordon]

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

Comment 5

[Dave Miller [:justdave]]

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]]

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

Comment 7

[Frédéric Buclin]

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 9

[Bishop Clark (LC957)]

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]]

See also bug 185041.

Comment 11

[Marc Schumann [:Wurblzap]]

See also bug 102048.

Comment 14

[Fedor Ezeev]

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]

Attachment: bugzilla-4.5.6-blocked.patch

Proposed patch

Comment 16

[Gervase Markham [:gerv]]

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]

(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]

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]

Attachment: 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]]

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]

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]

(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]

(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]

Attachment: 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

[:glob ✱]

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]

Hi, just checking in; I'm waiting for the review and suggestions on proper naming.

Comment 27

[Fedor Ezeev]

(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

[:glob ✱]

ratmir, are you ok with fedor taking over this bug?

Comment 29

[Ratmir Karabut]

(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]

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

[:glob ✱]

(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).

Comment 32

[Dave Miller [:justdave]]

:sigh:  trying to clean up loose stuff sitting around, hate that this sat here for 3 years, I haven't been paying attention much to my review queue (there hasn't been much in it and I haven't been directly involved in the code part of Bugzilla in a while).  Anyhow, neither of these patches will apply to the current code base, all but one chunk fails.

I did update the patch for the current code, it mostly got nailed by other fields getting added in the same spot. :)

Comment 33

[Dave Miller [:justdave]]

Attachment: Github Pull Request

Moving the patch to Github

Comment 34

[Fedor Ezeev]

Any news?
Can I do something to help push this code to any release?