View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004808 | mantisbt | reports | public | 2004-11-04 04:03 | 2004-12-11 03:01 |
Reporter | mno | Assigned To | thraxisp | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 0.19.0 | ||||
Fixed in Version | 0.19.2 | ||||
Summary | 0004808: Not exactly true data shown in graphs | ||||
Description | I have noticed that the graph "cumulative by date", which I find really usefull, does not show allways the truth. | ||||
Additional Information | I believe that in the main mantis table, there should be additional field, apart from date_submitted and last_updated, namely: date_resolved, or maybe even another table date_resolved which would contain the bug ID and the date it was resolved. The question is what to do when a bug was reopened and than resolved again. Do we take the last resolved day? I would say yes, because if reopened, it means that it has not been actually resolved. | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
The changes made in the summary page need to be ported to the graph. |
|
Reminder sent to: mno Hi. I see, in this issue, that you have dates in x-label with cumulative by date graph. I don't. Did you do anything to get it work ? Wich version of JPGraph do you use ? Thanks. |
|
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_updatedFROM $t_bug_tableWHERE $specific_where ANDstatus >='$t_res_val'ORDER BY last_updated";$query = "SELECT MAX(mantis_bug_history_table.date_modified) as 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. |
|
|
|
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. |
|