The default bug view has changed. See this FAQ.

query on bugs not depending on un-fixed bugs

NEW
Assigned to

Status

()

Bugzilla
Query/Bug List
P3
enhancement
16 years ago
a year ago

People

(Reporter: Adam Hauner, Assigned: Ratmir Karabut)

Tracking

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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.
This is kind of bug #8527, except statuses should be customisable (bug #101179),
and moving to ASLEEP might not be automatic.
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.20

Comment 2

15 years ago
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: normal → enhancement
(Reporter)

Updated

14 years ago
Summary: [RFE] query on bugs not depending on un-fixed bugs → query on bugs not depending on un-fixed bugs

Comment 3

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

Comment 4

14 years ago
*** Bug 168803 has been marked as a duplicate of this bug. ***
Assignee: endico → nobody
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.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
*** Bug 252461 has been marked as a duplicate of this bug. ***
Blocks: 16743

Comment 7

12 years ago
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).
Target Milestone: Bugzilla 2.22 → ---

Updated

11 years ago
QA Contact: mattyt-bugzilla → default-qa

Updated

10 years ago
Duplicate of this bug: 349750

Comment 9

10 years ago
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.
See also bug 185041.
See also bug 102048.

Updated

10 years ago
Duplicate of this bug: 332544
Assignee: nobody → query-and-buglist

Updated

4 years ago
Duplicate of this bug: 823562

Comment 14

2 years ago
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

2 years ago
Created attachment 8532912 [details] [diff] [review]
bugzilla-4.5.6-blocked.patch

Proposed patch
Attachment #8532912 - Flags: review?(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
(Assignee)

Comment 17

2 years ago
(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?
(Assignee)

Comment 18

2 years ago
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.
(Assignee)

Comment 19

2 years ago
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.
Attachment #8533334 - Flags: review?(gerv)

Updated

2 years ago
Attachment #8532912 - Flags: review?(gerv) → review-

Updated

2 years ago
Attachment #8532912 - Flags: review-
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
Attachment #8533334 - Flags: review?(gerv) → review?(LpSolit)

Comment 21

2 years ago
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.
Attachment #8533334 - Flags: review?(LpSolit) → review?(glob)
(Assignee)

Comment 22

2 years ago
(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?
(Assignee)

Comment 23

2 years ago
(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

2 years ago
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.
Attachment #8532912 - Attachment is obsolete: true
Attachment #8542004 - Flags: review?(LpSolit)

Updated

2 years ago
Attachment #8542004 - Flags: review?(LpSolit) → review?(glob)
Assignee: query-and-buglist → rkarabut
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.
Attachment #8542004 - Flags: review?(glob)
(Assignee)

Comment 26

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

Comment 27

2 years ago
(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 :)
ratmir, are you ok with fedor taking over this bug?
Flags: needinfo?(rkarabut)
(Assignee)

Comment 29

2 years ago
(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
Flags: needinfo?(rkarabut)

Comment 30

2 years ago
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?
Flags: needinfo?(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).
Flags: needinfo?(glob)
Attachment #8533334 - Flags: review?(glob) → review?(justdave)
You need to log in before you can comment on or make changes to this bug.