Changes between Version 37 and Version 38 of AnalyzePlugin

Timestamp:

May 15, 2013, 9:11:22 AM (11 years ago)

Author:

Ryan J Ollos

Comment:

Added syntax highlighting.

AnalyzePlugin

@@ -19 +19 @@
  1. Install the plugin (after downloading and unzipping):
     {{{
+    #!sh
     cd analyzeplugin/0.12
     sudo python setup.py bdist_egg
@@ -28 +29 @@
  2. Enable the plugin:
     {{{
+    #!sh
     [components]
     analyze.* = enabled
@@ -73 +75 @@
 To enable this analysis for a given report, list those reports in {{{trac.ini}}} as follows:
 {{{
+#!ini
 [analyze]
 milestone_reports = 1,9
@@ -86 +89 @@
 This 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:
 {{{
+#!ini
 [analyze]
 queue_reports = 2,9
@@ -93 +97 @@
 The {{{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:
 {{{
+#!ini
 [analyze]
 queue_fields.9 = queue
@@ -99 +104 @@
 In 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):
 {{{
+#!ini
 [analyze]
 queue_fields.9 = queue,type!=epic,phase!=verifying|releasing
@@ -114 +120 @@
 This 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:
 {{{
+#!ini
 [analyze]
 project_reports = 19
@@ -125 +132 @@
 The 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:
 {{{
+#!ini
 [analyze]
 refresh_report = 9?max=1000
@@ -140 +148 @@
 To enable this analysis for reports, list those reports in {{{trac.ini}}} as follows:
 {{{
+#!ini
 [analyze]
 rollup_reports = 1,2,3,9
@@ -156 +165 @@
 All 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:
 {{{
+#!ini
  [analyze]
  rollup.effort = sum