37990 - Suggest component for those commonly misassigned

Status: NEW

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

Description

[Jesse Ruderman]

It would be nice to be able to find the answer to questions such as "I know 
this isn't a networking bug, so where components do bugs filed against 
networking often end up?"  Low priority, but it would be cool.  The reverse 
might also be useful, because it might point out what components have sucky 
descriptions on describecomponents.cgi.

Comment 1

[Dave Miller [:justdave]]

The way you worded this isn't all that clear, so I'm just trying to help clarify 

it if I can....



Are you wanting Bugzilla to keep track of what component an item was originally 

assigned to, no matter where it finally ends up, so that you can go back later 

and see what component bugs reported to a given component ultimately end up in?



If that's what you're looking for, that information is already stored in the 

bugs_activity table, so it wouldn't be too hard to come up with.  It would 

probably take me a couple minutes to put together a query that would pull this 

from the database.  I'm not sure how much of a performance hit it would create, 

so we might want to make it an option (i.e. link at the bottom of the component 

list "redisplay with reassignment counts" or something like that).

Comment 2

[Jesse Ruderman]

Sounds like you understand what I want.  Thanks for clarifying it.

Since this information wouldn't change very often, why not just pull it from 
the database every several days (and each time a new component is added) and 
put it up as a static page?  That should mostly take care of the performance 
problem.

Comment 3

[Dave Miller [:justdave]]

OK, the following query will pull the information you're looking for:

        SELECT bugs_activity.newvalue, COUNT(*) AS count
        FROM bugs_activity LEFT JOIN fielddefs
              ON fielddefs.fieldid = bugs_activity.fieldid
        WHERE IFNULL(fielddefs.name, bugs_activity.fieldid) = "component"
              AND bugs_activity.oldvalue = "$component"
        GROUP BY bugs_activity.newvalue
        ORDER BY count DESC;

Replace $component with the name of the component you're looking at, and this 
will return each component that one has been reassigned to, with a count of how 
many times it's been reassigned to that component, with the component with the 
most reassignments at the top.

Just exactly how to integrate this information into describecomponents.cgi, I'm 
not sure.  Anyone have suggestions?

Comment 4

[Dave Miller [:justdave]]

Made another revision to that...  the following query is a little more accurate:

        SELECT bugs_activity.newvalue, COUNT(*) AS count
        FROM bugs_activity
              LEFT JOIN fielddefs
              ON fielddefs.fieldid = bugs_activity.fieldid
              LEFT JOIN bugs
              ON bugs_activity.bug_id = bugs.bug_id
        WHERE IFNULL(fielddefs.name, bugs_activity.fieldid) = "component"
              AND bugs_activity.oldvalue = "$component"
              AND bugs.product = "$product"
        GROUP BY bugs_activity.newvalue
        ORDER BY count DESC;

The difference here being that we're checking against the product, as well, since 
it is theoretically possible to have components in more than one product that 
have the same name (but aren't the same component because they belong to 
different products).

Comment 5

[Dave Miller [:justdave]]

was looking at this again because someone changed a CC :-)

Anyhow, looking over my previous comments, I think that last query will fail to 
find the correct components if the component it got changed to wound up in a 
different product, as well, since it's searching on the current component, and 
not the original one...

Comment 6

[Dave Miller [:justdave]]

er, current product, not current component...

Comment 7

[Dave Miller [:justdave]]

-> Bugzilla product