The changes made in the summary page need to be ported to the graph.

Fixed in CVS.

Added date lookup from history table as in summary_page.php.

Actually it is not what I have expected, because my curve still behaves like we have done a lot better recently than in the past with bug fixing, which is not true. In the function you just implemented, there is a comment saying that "we should look for the last time it was RESOLVED in the history" but in the function you use $t_clo_val instead of $t_res_val. If we change that, the graph is almost what I am looking for, but not exactly, because there are cases where bugs are closed directly withoug going through 'resolved' state.

Interestingly I decided to fix the problem myself yesterday (what a coincidence) and here is my solution. I commented out those query lines and replaced it with my own query.

$query = "SELECT last_updated

FROM $t_bug_table

WHERE $specific_where AND

status >='$t_res_val'

ORDER BY last_updated";

$query = "SELECT MAX(mantis_bug_history_table.date_modified) as last_updated
FROM mantis_bug_table, mantis_bug_history_table
WHERE mantis_bug_table.id = mantis_bug_history_table.bug_id
AND mantis_bug_history_table.new_value >= '$t_res_val'
AND mantis_bug_table.status >= '$t_res_val'
AND mantis_bug_history_table.old_value < '$t_res_val'
AND mantis_bug_history_table.field_name = 'status'
AND $specific_where
GROUP BY mantis_bug_history_table.bug_id
ORDER BY last_updated ";

Which I believe is right. (I might be still wrong). Of course it is not very nice, because I use 'mantis_bug_table' and 'mantis_bug_history_table' names directly. I am also not sure if the last ORDER BY should be with DESC, or maybe we could dispence with that. Both work, but maybe one is faster than the other (which?). And the 'last_updated' label should be replaced with 'recently_resolved_or_closed_date' label. I used 'last_updated', because this label is used later on in that function, and did that just for the simplicity of it.

In my solution, I do not take either 'resolved' or 'closed', i do consider both states, under condition that the previous state was something below 'resolved'. And in my opinion that is the final solution.

If it will be possible, I will post some graphs too.

I just uploaded three graphs, the first one is the one that is shown after your fix from yesterday. The second one is your fix after I changed $t_clo_val to $t_res_val. The third one is my own fix. Those last two look almost the same, nevertheless they differ slightly.

What is interesting, my solution produces 6 uniqe queries, whereas yours 729, but I haven't noticed any difference in processing time.

A new change was submitted to CVS incorporating nmo's change and modifying it to account for bugs without history.

1. Actually it still doesn't work. It only works properly when we remove the OR from the SQL query (otherwise what comes after the 'OR' is used).

2. The change you did with the date to smooth the curve, destroys the date information on the x-axis. You should rather do something like that:

   date = my_date - my_date % 86400;

and the condition which you removed:

AND mantis_bug_table.status >= '$t_res_val'

has to be there, because if a bug was reopened and is currently in reopened state, it should not be treated as resolved, but without the line - it will be, because it will find a line in the history that it has once been resolved.

If we remove the "OR" clause, then any resolved issues entered before 0.18.0 are not counted. The way the logic should work is that the history data is used, unless it doesn't exist, then it defaults to the last_updated field.

I'll look into the other issues.

Ok, I understand that it has to be backward compatible, but it has to be somehow rewriten, because at the moment, for the new installations it still takes the old data.

Not that I want to be importunate. I have my version running properly, so myself I do not need this to be fixed. I just want to help you guys and other people who use Mantis.

sorry, I meant "dont want to be importunate" :)

Another version has been committed to CVS.

The rounding to days has been fixed.
The query has also been updated to fetch as much information as is available, then refine in php to address three cases: history contains unresolved to resolved transition, history is present, but doesn't contain the transition, and there is no history.