Changes between Version 37 and Version 38 of AnalyzePlugin


Ignore:
Timestamp:
May 15, 2013 11:11:22 AM (16 months ago)
Author:
rjollos
Comment:

Added syntax highlighting.

Legend:

Unmodified
Added
Removed
Modified
  • AnalyzePlugin

    v37 v38  
    1919 1. Install the plugin (after downloading and unzipping): 
    2020    {{{ 
     21    #!sh 
    2122    cd analyzeplugin/0.12 
    2223    sudo python setup.py bdist_egg 
     
    2829 2. Enable the plugin: 
    2930    {{{ 
     31    #!sh 
    3032    [components] 
    3133    analyze.* = enabled 
     
    7375To enable this analysis for a given report, list those reports in {{{trac.ini}}} as follows: 
    7476{{{ 
     77#!ini 
    7578[analyze] 
    7679milestone_reports = 1,9 
     
    8689This analysis detects when a ticket in a given report has a dependency (a {{{blockedby}}} ticket) whose {{{position}}} comes after this ticket's (or has no {{{position}}} yet at all, or is not in the correct queue).  To enable this analysis for a given report, list those reports in {{{trac.ini}}} as follows: 
    8790{{{ 
     91#!ini 
    8892[analyze] 
    8993queue_reports = 2,9 
     
    9397The {{{queue_fields}}} (optional) above tells this analysis what fields (if any) define (i.e., segment) a queue.  Queues can be defined by zero or more fields such as the {{{milestone}}} field, a custom {{{queue}}} field, both or other fields.  If you have different reports using different definitions, you can define report-specific queue field definitions as follows: 
    9498{{{ 
     99#!ini 
    95100[analyze] 
    96101queue_fields.9 = queue 
     
    99104In this example, report 2 uses both {{{queue}}} and {{{milestone}}} fields to define a queue whereas report 9 uses only the {{{queue}}} field.  You may also specify additional filters to skip tickets with certain field values (pipe-delimited): 
    100105{{{ 
     106#!ini 
    101107[analyze] 
    102108queue_fields.9 = queue,type!=epic,phase!=verifying|releasing 
     
    114120This analysis will enforce that the child tickets (usually found in a separate work queue report) are ordered relative to one another in the same general order as the parent/project tickets.  To enable this analysis for a given report, list those reports in {{{trac.ini}}} as follows: 
    115121{{{ 
     122#!ini 
    116123[analyze] 
    117124project_reports = 19 
     
    125132The default behavior of an analysis is to refresh the current report if any fixes were made.  This is so that changes can be viewed (assuming they would change the content of the report).  In the case of the Project Queue Analysis, you would usually also need another report refreshed - i.e., the impacted work queue.  Use the {{{refresh_report}}} option to specify this impacted work queue which will also get refreshed at the end of this analysis if there were any fixes.  You can add params to the report as well if needed: 
    126133{{{ 
     134#!ini 
    127135[analyze] 
    128136refresh_report = 9?max=1000 
     
    140148To enable this analysis for reports, list those reports in {{{trac.ini}}} as follows: 
    141149{{{ 
     150#!ini 
    142151[analyze] 
    143152rollup_reports = 1,2,3,9 
     
    156165All but {{{pivot}}} apply to numeric fields, and all but {{{sum}}} apply to select option fields.  Here are several examples of specifying a stat for different fields: 
    157166{{{ 
     167#!ini 
    158168 [analyze] 
    159169 rollup.effort = sum