I noticed this today too. In my setup, it is very annoying, since my clients only have access to their projects and shouldn't even be aware of other projects.

Also, the issue isn't just the "longest open issue" field. Its all of the "Time Stats For Resolved Issues" fields - Longest Open, Average Time, and Total Time are also affected. I added a brand new project today and it is showing bogus time stats - although "Total Time" of 1471.73 for a 1-day old project is amusing, its not helpful.

I was expecting that these fields would reflect the currently selected project like the rest of the stats on the summary page.

Same here, it came to my notice when my manager asked why is there such a long open issue in my project, on seeing the summary report.

Hi there,

we've also noticed that problem in a similar situation as scorpfromhell. Really uncomfortable :(

As a quick fix (without further testing if it effects anything other) i changed the SQL statement (starting on line 54 in current version) in the summary_page.php to look as follows:

$query = "SELECT b.id, b.date_submitted, b.last_updated, MAX(h.date_modified) as hist_update, b.status
FROM $t_bug_table b LEFT JOIN $t_history_table h
ON b.id = h.bug_id AND h.type=0 AND h.field_name='status' AND h.new_value='$t_resolved'
WHERE b.status >='$t_resolved'
AND project_id=$t_project_id
GROUP BY b.id, b.status, b.date_submitted, b.last_updated
ORDER BY b.id ASC";

That seems to solve the issue. Hasn't noticed any negative side effect yet.

Greets
Patrick Schönfeld
in medias res Gesellschaft für Kommunikationstechnologien mbH

Also i wanted to notice that i don't think that this value is useful at all. It does say nothing and if you have any bug that has been opened real long (until it got decided that it will never get fixed, because it is senseless or something) you don't have a chance to see a proper value in here.

imr's patch doesn't work when you select "All Projects" or when you select a parent project. It only works when you select a single project that has no sub-project.

There seems to be a partial fix in the 1.0.3 version. The variable "$specific_where" contains the correct SQL to use, but its never used. This SQL statement gets it to work in all cases (the change is "AND $specific_where" instead of "AND project_id=$t_project_id"):

$query = "SELECT b.id, b.date_submitted, b.last_updated, MAX(h.date_modified) as hist_update, b.status 
    FROM $t_bug_table b LEFT JOIN $t_history_table h 
        ON b.id = h.bug_id  AND h.type=0 AND h.field_name='status' AND h.new_value='$t_resolved'  
        WHERE b.status >='$t_resolved' 
        AND $specific_where
        GROUP BY b.id, b.status, b.date_submitted, b.last_updated 
        ORDER BY b.id ASC";

Personally I find these metrics to be very useful, although as imr observed they can become meaningless if you end up with an abandoned bug in there. But if you keep an eye on the stat you can use it to help prevent getting abandoned bugs in the first place.

See duplicate entries for this in 0007498, 0007374, 0007022, 0006632 (list of other related entries here!) and 0006223 (which contains a fix that worked for me!)

this code from ssexton's note is in 1.1.0a2.