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.

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

removing target milestone from WONTFIX/INVALID/WORKSFORME/DUPLICATE bugs so they'll show up as untriaged if they get reopened.