Author: Victor Boctor

The Mantis database contains a snapshot of the information at a point in time, hence, the reports on it can only do the same. As far as project management is concerned, it is often needed to track changes over time. For example, how is the number of bugs opened per day and bugs resolved per day vary as the project gets closer to the release date?

This can be done by savings metrics at certain times and then reporting at this metrics. These metrics are called performance counters, and they can be calculated as often as necessary. By default, counters will be calculated daily.

• mantis_perf_counters_def_table
  • perf_counter_def_id
  • name = string (64)
  • function = Name of function to call to calculate the value (this is prefixed by perf_counter_calc_*).
  • params = string (255) - format is typically as follows: project_id=2,user_id=0,field3=value3
  • frequency = frequency in hours (e.g. 24 for performance counters that should be calculated daily).
  • enabled = boolean

• mantis_perf_counters_val_table
  • perf_counter_val_id
  • perf_counter_def_id
  • timestamp
  • value (int) or double?

A script will be added that will calculate all the enabled performance counters that are due to calculation. The algorithm should be as follows:

for each enabled counter
   if no previous recorded values or last recorded greater than "frequency" hours then
      calculate the performance counter and record the value.

• performance_counters_manage_threshold - add/delete

• Add counters: This can be done through the web interface as long as the function that calculates them is available.
• Modify counters: We shouldn't really be able to change the parameters sent to the counter calculator. If done then we need to delete all historical values. Hence, delete/add will be used.
• Delete counters: Deletes the counter definition as well as all historical values.

• Number of issues
  • status (optional) (e.g. value|value|value)
  • priority (optional) (e.g. value|value|value)
  • severity (optional) (e.g. value|value|value)
  • category (optional)
• Number of opened issues since last calculation based on date_submitted
  • priority (same as above)
  • severity (same as above)
  • category (save as above)
• Number of resolved issues
  • This can be done using tokens. A token can be used to store the last value. The number resolved = total number in previous run - total run in current run + total number reported.

A company wants to keep a performance counter for the number of issues that has priority 1 and have been open for more than 3 days. This counter is to be called “sla_slips”.

function perf_counter_calc_sla_slips( $p_params ) {
    $t_priority = $p_params['priority'];   // will be set to 1
    $t_days = $p_params['days'];  // will be set to 3
 
    // calculate the number here and store in $t_counter.
 
    return $t_counter;
}

• Are we going to provide a generic interface to view counters?
• If so,
  • it should be possible to graph multiple counters in the same graph.
  • we should add a view access level to the definition table.
• The other option is to store this information in the database and have the access control implemented in the reports that access the performance counters.

Put your feedback in this section.