+++ This bug was initially created as a clone of Bug #12286 +++ Bug #12286 adds a "See Also" field, which is different from the original "Related Bugs" feature. This ticket addresses the symmetrical related bugs feature. The key differences are: See Also - Only one ticket number - Asymmetrical - Requires the full URL such that it can refer to other ticketing systems. Related Bugs - Multiple ticket numbers - Symmetrical - Only needs the number, referencing the same bugzilla system. In a sense, related bugs is just like dependson/blocks, except bugs can be closed regardless the status of the related bugs.

For what it's worth, I've updated the original bug 12286 patch to work in 3.4.4. Long term, this should be done via a custom bug_list field. Yet unclear when such a feature will be available.

This is related to the work in bug 287334. Pay attention to bug 287334 comment 19: For now we will implement this as a single bug id. We can later change the type to take a list.

I would like to expand this a bit. Here are relations from other bug systems that would be great to have (potentially by default): - related (what this bug is about) * Useful for loosely tying bugs together, adding pointers to other similar bugs, or keeping track of related issues while you determine the proper relationship * Had this in Radar @ Apple and we used it ALL the time. I feel blind without it. - clone from, clone to * Super helpful to explicitly track where bugs came from, etc * Not user editable, though potentially could let a user delete the relationship - subtask, supertask * Calls out this relationship explicitly, provides a difference between blocking (needs something else) and subtask (part of something else) - regression from, caused regression * Again, super useful to trace back what happened and make sure we didn't miss something - test for, tested by * Not sure how useful these would be, but then we could have one bug for the test and one for the actual fix - continuation of, continued by (?) * Not really sure about this one, though I could see it being possibly useful. We often miss followup fixes on branches. This would be something we could explicitly look for as release drivers. - duplicate, original * We already have this, but I want the duplicate to show up in the original's related bug list Possible UI is a collapsible, sortable table of bugs and relations (and calling out the # of duplicates in the table title so that you can quickly see bugs with lots of dupes): +----------------------------------------------------------------------------+ [v] Related Bugs (2 Duplicate) | +----------------------------------------------------------------------------+ | Add (related[v]) [______________________] [Add] | +----------------------------------------------------------------------------+ | Bug Id | Relation | Title/Summary | +----------------------------------------------------------------------------+ | 999999 | original of | [Duplicate bug title] | | 888888 | related to | Some other bug | | 777777 | related to | Yet another other bug | | 666666 | original of | [Duplicate #2 bug title] | | 555555 | cloned to | [the cloned bug title] | +----------------------------------------------------------------------------+

This is something that we have thought about doing as well. This is similar to how other trackers do this such as JIRA. Basically you just need a couple of tables, one 'relationship_type' table that lists the different types of possible relationships such as Dependency, Duplicate, Relates, Incorporates, etc. Then another generic mapping table called 'relationship' that has the bug_id, source_id, destination_id, and type_id. The rest is mostly template work as you have laid out which looks good and backend code work to read/store/verify/edit the values in the mapping table. Then other types can be added in the future as needed. Dave

FTR: Original bug 12286 of which this is a clone was posted 1999 and has 55 votes. In view of which it may not be a good idea to wait for the perfection of comment 3 (unless we want to wait another 5 years). Instead, I propose: 1) implement Bug 479550: Allow "Bug ID" fields to contain more than one Bug ID 2) then implement the straightforward version of this bug (if not as a default field for bugzilla installations, then at least as a custom field on bmo!) Looking at Max' bug 479550 comment 1 it doesn't look as if it is a big problem to do, given that same/similar functionality already exists in the depends-on and blocks fields, albeit hard-coded.

FWIW, I am working on this and will have a patch to nominate soon. This will be my first Bugzilla patch though, not sure how long it will take to get in landing shape. I'll attach a WIP probably within the week (got some good feedback from people at the summit)

I'm reworking my patch a bit based on a conversation with Max.

that is what i think bugzilla needs, I know we have products and components and all, but sometimes it seems it would be nice to just have meta bugs list all the related bugs.. since they are not necessarily dependency or blockers, but they are just associated with Feature X. Creating a ability to update related bugs could reduce comments and make it easy to track more bugs that get lost in the cracks of searching and being not connected to any other bugs but the area of expertise. Adding this could bring some much needed help in this area of bug tracking and being able to stay organized.

So, I said I'd put up a WIP but I was away at Black Hat and DefCon last weekend. I need to re-architect this a bit and clean/polish it now that I am a little more familiar working with Bugzilla. I'm attaching a image showing the current state as a teaser :-). Don't mind that it's ugly...I haven't styled it, done any JS, etc.

@Christian Cool! :-) FWIW, the UI will have to be different--there are sometimes many, many, many ids in the "Depends On" and "Blocks" fields. Instead, I think that what you want to do is something more like: Depends On: 1, 2, 3, 4 Blocks: 1, 2, 3, 4 ------------------ ------------- | Caused By: | v | | | ------------------ ------------- And then selecting Caused By or entering some data into the field creates a new row below with everything except DependsOn, Blocks, and CausedBy in the drop-down.

Having filed the request for this about 11 years ago, I heartily approve ... ;) Off memory there at least used to be some sort of feature where you couldn't close a bug until you closed the blockers, so I guess there'd have to be some sort of option for each relationship type as to whether this applies.

(In reply to comment #12) > @Christian Cool! :-) FWIW, the UI will have to be different--there are > sometimes many, many, many ids in the "Depends On" and "Blocks" fields. > Instead, I think that what you want to do is something more like: > > Depends On: 1, 2, 3, 4 > Blocks: 1, 2, 3, 4 > ------------------ ------------- > | Caused By: | v | | | > ------------------ ------------- > > And then selecting Caused By or entering some data into the field creates a > new row below with everything except DependsOn, Blocks, and CausedBy in the > drop-down. I'm planning on having the table a set vertical size and letting it scroll, with a button or grab handle to resize 100% vertically via JS. This is the UI I am familiar with and have seen it scale fairly well, though I will play around with other suggestions. (In reply to comment #13) > Having filed the request for this about 11 years ago, I heartily approve ... ;) > > Off memory there at least used to be some sort of feature where you couldn't > close a bug until you closed the blockers, so I guess there'd have to be some > sort of option for each relationship type as to whether this applies. Yeah, I've been thinking about this. Currently I have a way to mark the relationship as "system_add" which means that only bugzilla can add a relationship (for the case of clone) and "system_remove", which means only bugzilla can remove a relation (haven't really thought of a use case, but whatever). Both of them together means it is a relationship bugzilla maintains entirely. I need to add the closing blocking bit as well as support for specifying which relationships should be included in time-tracking calcs.

(In reply to comment #12) > @Christian Cool! :-) FWIW, the UI will have to be different--there are > sometimes many, many, many ids in the "Depends On" and "Blocks" fields. > Instead, I think that what you want to do is something more like: > > Depends On: 1, 2, 3, 4 > Blocks: 1, 2, 3, 4 > ------------------ ------------- > | Caused By: | v | | | > ------------------ ------------- > > And then selecting Caused By or entering some data into the field creates a > new row below with everything except DependsOn, Blocks, and CausedBy in the > drop-down. Caused by is really only great when its a regression, and maybe that also would be a specific field. But I think see also or related in general can be more wide spread to include a list of bugs.

We shouldn't have a "cloned from" relationship. Instead, when you clone a bug, you should be able to choose any of the (meaningful) relationship types, such as "regression caused by" or "branch version of" or "requires". So I don't know that we need any relationships that "can only be set by Bugzilla itself".

(In reply to comment #14) > I'm planning on having the table a set vertical size and letting it scroll, > with a button or grab handle to resize 100% vertically via JS. I'd really rather not do that. Nearly all of our current meta-bugs would become painfully difficult to understand at a glance, with that UI. Nobody complains about the current Depends On and Blocks UI--I don't see any reason to develop a new UI. > Yeah, I've been thinking about this. Currently I have a way to mark the > relationship as "system_add" which means that only bugzilla can add a > relationship (for the case of clone) and "system_remove", which means only > bugzilla can remove a relation (haven't really thought of a use case, but > whatever). Both of them together means it is a relationship bugzilla maintains > entirely. Well, let's start off with a simple patch and not worry about that for now. Also, as Jesse says, we probably don't need system_add/remove. > I need to add the closing blocking bit as well as support for specifying which > relationships should be included in time-tracking calcs. That's something you can add in a later bug, and just hack in support for noresolveonopenblockers for now.

(In reply to comment #17) > (In reply to comment #14) > > I'm planning on having the table a set vertical size and letting it scroll, > > with a button or grab handle to resize 100% vertically via JS. > > I'd really rather not do that. Nearly all of our current meta-bugs would > become painfully difficult to understand at a glance, with that UI. Nobody > complains about the current Depends On and Blocks UI--I don't see any reason to > develop a new UI. Ok. Like I said I'll play around, though I'll probably stick to what you want. Attached is a ss after I prettied up the table a bit with YUI (using progressive enhancement of course) > > > Yeah, I've been thinking about this. Currently I have a way to mark the > > relationship as "system_add" which means that only bugzilla can add a > > relationship (for the case of clone) and "system_remove", which means only > > bugzilla can remove a relation (haven't really thought of a use case, but > > whatever). Both of them together means it is a relationship bugzilla maintains > > entirely. > > Well, let's start off with a simple patch and not worry about that for now. > Also, as Jesse says, we probably don't need system_add/remove. Ok, I wasn't sure if this feature should be all-encompassing or if I could get a review w/o those pieces included. > > > I need to add the closing blocking bit as well as support for specifying which > > relationships should be included in time-tracking calcs. > > That's something you can add in a later bug, and just hack in support for > noresolveonopenblockers for now. Sounds good.

Good news: I haven't forgot about this and it's almost 100% functional Bad news: I now know more about bugzilla internals and am going to rework it yet again...*sigh*. Also been somewhat distracted working on http://github.com/LegNeato/bugzilla-amqp. This is my main bugzilla focus now though.

I wonder if we could land the "Related bugs" idea from comment #0 in the meantime?

If I could (bug#532474), I would thumbs up comment#16. I agree that where a bug was clone from isn't particularly useful. In fact, I always delete the dependencies and auto-generated comment almost every time I clone a bug in our system. Generally we use cloning when creating a bug sighting within another product. Typically these are dependencies such as a library that is tracked as it's own project or issues between two interdependent applications that are tracked as separate projects in Bugzilla.

(In reply to comment #21) > I wonder if we could land the "Related bugs" idea from comment #0 in the > meantime? This *is* that feature, more or less. There isn't going to be much difference between implementing that feature and implementing this feature. Also, you can use "See Also" for related bugs if you really want to.

Any progress on this? Last progress is from 14 months ago. Perhaps Christian Legnitto could provide his WIP so that other can <strikeout>steal</strikeout> continue work on it.