View Issue Details

WikiJump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0003710mantisbtbugtrackerpublic2004-04-01 06:412004-08-29 02:25
Reporternepto Assigned Tothraxisp  
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionfixed 
Fixed in Version0.19.0rc1 
Summary0003710: time stats in summary to use resolved
Description

There is in the changelog:

  • Modified time stats in summary to use CLOSED instead of resolved.

I think this could be made configurable.

Additional Information

Why? We at Platon.SK use resolved when bug is resolved. We keep it in the bug-tracking system till the next project release as reporter could see it and not to report already fixed bug. Once release is out and available for download, we close all of these bugs.

Thus real time needed for bug fixation is from open to resolved not from open to closed.

TagsNo tags attached.
Attached Files
time_summary.diff (1,148 bytes)    
Index: summary_page.php
===================================================================
RCS file: /cvsroot/mantisbt/mantisbt/summary_page.php,v
retrieving revision 1.38
diff -r1.38 summary_page.php
31a32
> 	$t_history_table = config_get( 'mantis_bug_history_table' );
33,34c34,35
< 	$t_clo_val = CLOSED;
< 	$query = "SELECT id, date_submitted, last_updated
---
> 	$t_clo_val = config_get( 'bug_resolved_status_threshold' );
> 	$query = "SELECT id, date_submitted, last_updated, status
36c37
< 			WHERE $specific_where AND status='$t_clo_val'";
---
> 			WHERE $specific_where AND status>='$t_clo_val'";
46a48,62
> 		$t_id = $row['id'];
> 		$t_status = $row['status'];
> 
> 		if ( $t_status <> $t_clo_val ) {
> 			$query2 = "SELECT date_modified
> 				FROM " . $t_history_table . "
> 				WHERE bug_id=$t_id AND type=" . NORMAL_TYPE . 
> 							" AND field_name='status' AND new_value=$t_clo_val
> 				ORDER BY date_modified DESC LIMIT 1";
> 			$result2 = db_query( $query2 );
> 			if ( db_num_rows( $result2 ) == 1 ) {
> 				$row2 = db_fetch_array( $result2 );
> 				$t_last_updated   = db_unixtimestamp( $row2['date_modified'] );
> 			}
> 		}
time_summary.diff (1,148 bytes)   
time_summary.zip (2,101 bytes)

Activities

vboctor

vboctor

2004-04-01 06:56

manager   ~0005315

I agree that this should be configurable. Another installation may want to consider a bug as finished when its status is moved to "tested" which is less than "resolved" and "closed".

Nepto, do you want to implement this change? If so, please contact me.
nepto

nepto

2004-04-04 16:28

reporter   ~0005341

Sorry, I currently do not have time for this.

Maybe later.
JamoSmith

JamoSmith

2004-07-14 09:51

reporter   ~0006041

this issue is causing distress in my version as well
thraxisp

thraxisp

2004-07-14 18:54

reporter   ~0006051

There is a simple fix, but it highlights a problem with the calculation. The current design only counts issues at the current "resolved" state, ignoring those that may be beyond this state.

The calculation could be improved using the history to find the transition to the resolved state.
thraxisp

thraxisp

2004-07-16 10:11

reporter   ~0006088

I'll look at fixing this, but would like some clarification.

The current code does the time calculations on all issues whose state is exactly the end state (say, resolved) and ignores those that are beyond that state (e.g., closed) or still unresolved.

My proposal would be to count all issues that are at or beyond the "resolved" state ($g_bug_resolved_status_threshold). For those beyond, I will attempt to adjust the resolved time using the stored history, if it exists.
thraxisp

thraxisp

2004-07-18 10:07

reporter   ~0006116

Patch for summary_page.php attached (as well as the modified source file).
vboctor

vboctor

2004-07-26 17:41

manager   ~0006378

thraxisp, I reviewed your patch and following are my comments:

  • The query you added has a LIMIT keyword, this is not allowed for portability reasons between different DBMSes. You can achieve the same functionality by sending an extra parameters to db_query().

  • You are extracting the "closed" timestamp from the history only if the current status is not equal to the close status. What if the issue is in the "closed" status but a bugnote is added to it? Note that in 0.19.0 there is a access level threshold above which all bugs are editable (independent of their status). I think you should probably run the query anyway.

  • You probably don't need to call db_num_rows(), you can call db_fetch_array() and make sure the return is !== false.

Once you apply the above comments, please commit your work. Thanks.
thraxisp

thraxisp

2004-07-26 19:20

reporter   ~0006380

updated in CVS