Closed Bug 141175 Opened 22 years ago Closed 22 years ago

Possibility to press a button on a bug thereby creating a new "sub-bug" that blocks the first bug

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement, P3)

Product:
Bugzilla
Component:
Creating/Changing Bugs
Version:
2.15
Platform:
x86
Other
Type:
enhancement

Tracking

()

Status:
RESOLVED DUPLICATE of bug 81642

People

(Reporter: jesper.hertel.arbejde, Assigned: myk)

Details

It would be nice to have a button called "Create sub-bug" or "Create blocking 
bug" on the show_bug.cgi page. 

When you press it, you should go to enter_bug.cgi with a default Product and 
Component identical to the first bug, and with a blocking relation to the first 
bug (i.e., the first bug should be made dependent on the new bug when the new 
bug is committed).

The new button could be placed to the far right of the "Bug xxxx depends on:" 
field, e.g. to the right of the "Show dependency tree" link.

(For symmetry, which I think is always to strive for, one could also add a 
button "Create super-bug" or "Create depending bug", placing this button to the 
right of the "Show dependency graph" link).

Background: I very often create "sub-bugs" on a bug, i.e. a bug that should be 
fixed before the first bug can be fixed. This is quite tedious to do right now, 
but with a button like the proposed it would be really easy - and fun! :o)
Likely dup of bug 81642
Hmm, I don't think it's exactly the same as Bug 81642, which is somewhat more 
complicated.

This request ('bug') seems more simple to me: The central idea is just to 
create a new bug that blocks the existing bug. The rest about copying all 
fields is not central and could be omitted. 

Actually, the most important thing would be the ability to enter a dependency 
relation already when entering a bug, i.e. on the enter_bug.cgi page. If this 
was possible, I guess this 'bug' could be implemented by a simple link from 
show_bug.cgi to enter_bug.cgi with a few fixed parameters (bugid and productid 
for the existing bug).
Bug 81642 has a bit different concept, especially when related to marking clones
as such in the backend DB. So I think this is a separate RFE, and a good one,
too. Jesper's comment 2 has a good implementation point, and that issue
(entering field values on bug entry) is already being handled in several other
bugs too. This one is particularly related to bug 112373.
I'm not sure what you mean by "different concept, especially when related to
marking clones as such in the backend DB." (I'm the reporter of that bug.)
If you are referring to the proposal to prepopulate the comment field with a
"Split off from bug xyz" text, then I'm happily willing to drop this feature.
I've been using the "Clone this bug" link in my own installation quite often
(and missing it in the b.m.o installation even more often), but I think I
"never" kept the "Split off" text in my description; I always deleted it. The
idea was just that it could be useful sometimes.

I think the task of creating a new bug which is directly related to the current
one is a general issue, and it may have a general solution. You could think of
filing a new dependency, a new blocker, maybe a dependency-wise unrelated bug,
or a "sibling" (i.e. a dependency of the current bug's parent in the dependency
tree) if we can specify a useful behaviour for the case where the current bug
has multiple parents. Like in the domino game, where you have several sides
where you can add your new token. Then there is the second dimension: whether to
copy all fields (except comments), or maybe just the product, or none.

Maybe this is an overgeneralization, but I think at least these two issues
belong together. 
I was mainly referring to Gerv's comment 11 on bug 81642 which hinted at marking
the clone bugs as such on the DB level. 

Given a bit more thought, I agree that this and bug 81642 could be considered a
more general issue. I still don't think this is a dupe of 81642 (as it is
currently summarized), but these _could_ be combined to be a bigger common RFE.
Either of these bugs could be morphed to be a "RFE: 'create dependant bug'
option". It would cover at least

a) adding clone bugs (with appropriate db markup)
b) adding blocker bugs ("children")
c) adding bugs dependant on the current bug ("parents")
d) adding "siblings"

I think this would be extremely useful, but it would also add even more
hard-to-understand stuff to the UI, so some careful design is needed.

Bug 112373 covers exactly what I meant by "the ability to enter a dependency 
relation already when entering a bug, i.e. on the enter_bug.cgi page." Thanks 
for pointing that out, Jouni.

If Bug 112373 were implemented, I think it would be easy to add the simple 
links I proposed to create parent and child bugs.

If you do not connect this bug to a more general solution (like perhaps Bug 
81642, I'm not sure), I think this RFE could be implemented sooner, simply 
because it requires less thought and preparation.

When a more general solution is implemented, it could simply take over from the 
simple one. No harm would be done, as far as I can see it.


Regarding the UI: I agree that more links makes the UI a bit more complicated 
to look at, but I guess this is another issue: Making different versions of the 
UI depending on user preferences (like "beginner", "advanced" etc.). I guess 
someone must have proposed that, although I don't know and can't find it when I 
try to search.
Field hiding is bug 31144, it could be used to hide many things. This is not
strictly speaking a field, so there probably should be different kind of "expert
mode" toggle for this. 

I wonder if this sort of tools could be arranged to the page footer as some sort
of user-configurable toolbar. Each user could then customize the necessary tools
through prefs (similar to customizing the preset queries' visibility).
> Actually, the most important thing would be the ability to enter a dependency 
> relation already when entering a bug, i.e. on the enter_bug.cgi page. If this 
> was possible, I guess this 'bug' could be implemented by a simple link from 
> show_bug.cgi to enter_bug.cgi with a few fixed parameters (bugid and productid 
> for the existing bug).

Right on the money. This bug is bug 112373, plus a small template customisation
for the person who wanted this feature.

I would be strongly against further complicating the show_bug UI with this -
it's too niche.

Gerv
I don't think this is niche, I think it would see common usage actually.  I'll
move this to 2.18 for now but feel free to continue to argue about implementing it.
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.18
>I would be strongly against further complicating the show_bug UI with this -
>it's too niche.

I tend to agree with Matty on this: I don't think it's that niche. As one
example, our installation has the continous need to spawn new bugs from existing
tasks. This is mainly because we use Bugzilla fairly liberally with many sorts
of tasks, and a simple feature request often turns into a load of small bugs
with dependency relationships.

Couldn't say about other people's usage patterns though, but I can imagine they
have similar needs. Doesn't b.m.o, then? Maybe not as frequently, since bugs
here tend to be quite big in scale and thus have less dependencies... Dunno. 
Sorry Jouni, I can't figure out what "b.m.o" means?
"b.m.o" means bugzilla.mozilla.org. Similarly, n.p.m.webtools means the
newsgroup netscape.public.mozilla.webtools. Have we got a jargon file somewhere?
bug 81642 is the right approach for this.  Having both of these would be
overkill, and you could do what's suggested in this bug if 81642 were
implemented.  (Which it will be sooner than we all think - it has a corporate
sponsor now).

*** This bug has been marked as a duplicate of 81642 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
removing target milestone from WONTFIX/INVALID/WORKSFORME/DUPLICATE bugs so
they'll show up as untriaged if they get reopened.
Target Milestone: Bugzilla 2.18 → ---
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.