Changes between Version 43 and Version 44 of AnalyzePlugin


Ignore:
Timestamp:
Sep 8, 2017, 9:56:27 PM (7 years ago)
Author:
figaro
Comment:

Further cosmetic changes

Legend:

Unmodified
Added
Removed
Modified

  • AnalyzePlugin

    v43 v44  
    1414All of the analyses above build upon the [wiki:MasterTicketsPlugin master tickets plugin]. The second and third analyses also build upon the [wiki:QueuesPlugin queues plugin]. Be sure to use the latest version of the queues plugin so that the included jquery-ui versions match to avoid conflicts!
    1515
    16 See below for examples.
     16When an analysis is enabled for a report, an '''Analyze...''' button appears at the top of the report, which will present the user with the following dialog box:
    1717
    1818[[Image(ask_analyze.png, border=2)]]
     19
     20See below for further examples.
    1921
    2022== Bugs/Feature Requests
    … …  
    6870==== Milestone Dependency Analysis
    6971
    70 The popular [wiki:MasterTicketsPlugin master tickets plugin] enables specifying dependencies amongst tickets and visualizes them via graphviz. However, the plugin doesn't include support to manage these dependencies such as detecting when tickets are scheduled out of order. That's where this Milestone Dependency Analysis comes in:
     72The popular [wiki:MasterTicketsPlugin master tickets plugin] enables specifying dependencies amongst tickets and visualizes them via Graphviz. However, the plugin doesn't include support to manage these dependencies, such as detecting when tickets are scheduled out of order. That's where this Milestone Dependency Analysis comes in:
    7173
    7274[[Image(issue-milestone.png, border=2)]]
    … …  
    8789==== Queue Dependency Analysis
    8890
    89 The [wiki:QueuesPlugin queues plugin] converts one or more reports into work queues. These queues enable you to drag and drop tickets above and below one another signifying their relative priority. Each ticket's relative position is maintained in a custom field usually named {{{position}}} (but can be named anything). Dependencies amongst peer tickets in a work queue have similar problems as tickets across milestones, in this case a dependent ticket should precede, ie appear higher in the queue which means have a lower {{{position}}} value, but it can be difficult to manually catch all of these dependency violations. That's where this Queue Dependency Analysis comes in:
     91The [wiki:QueuesPlugin queues plugin] converts one or more reports into work queues. These queues enable you to drag and drop tickets above and below one another signifying their relative priority. Each ticket's relative position is maintained in a custom field usually named {{{position}}}, but can be named anything. Dependencies amongst peer tickets in a work queue have similar problems as tickets across milestones, in this case a dependent ticket should precede, ie appear higher in the queue, which means have a lower {{{position}}} value. However, it can be difficult to manually catch all of these dependency violations. That's where this Queue Dependency Analysis comes in:
    9092
    9193[[Image(issue-queue.png, border=2)]]
    … …  
    112114In this example, the {{{queue}}} field defines the queue in report 9 and the analysis will skip any ticket in this queue with {{{type}}} equal to "epic" or {{{phase}}} equal to "verifying" or "releasing". These would typically match the {{{WHERE}}} clause in the report's SQL.
    113115
    114 Detected problems are shown with an option to automatically fix the problem by moving tickets above or below each other in the queue - see screenshot above.
     116Detected problems are shown with an option to automatically fix the problem by moving tickets above or below each other in the queue, see screenshot above.
    115117
    116118==== Project Queue Analysis
    117119
    118 This analysis is for ''project'' queues (instead of work queues) meaning that the dependency semantics is parent-child. For example, you may have a report of project (or "epic" in agile-speak) tickets whose sub-tasks are represented in their {{{blockedby}}} dependencies. Re-prioritizing a project/epic/parent ticket does not automatically re-order their child tickets, respectively. That's where this Project Queue Analysis comes in:
     120This analysis is for ''project'' queues rather than work queues, meaning that the dependency semantics is parent-child. For example, you may have a report of project (or "epic" in agile-speak) tickets whose sub-tasks are represented in their {{{blockedby}}} dependencies. Re-prioritizing a project/epic/parent ticket does not automatically re-order their child tickets, respectively. That's where this Project Queue Analysis comes in:
    119121
    120122[[Image(issue-project.png, border=2)]]
    … …  
    131133The {{{project_type}}} option above is the ticket type of your projects, eg "epic" (the default), "project", etc. Project tickets must be of this type.
    132134
    133 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 - ie 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 parameters to the report as well if needed:
     135The 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, ie 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 parameters to the report as well if needed:
    134136{{{#!ini
    135137[analyze]
    … …  
    139141This analysis uses the same queue fields configuration as the Queue Dependency Analysis above.
    140142
    141 Detected problems are shown with an option to automatically fix the problem by moving the sub-task/child tickets above or below each other in their queue (to match their parent's relative positions), see screenshot above.
     143Detected problems are shown with an option to automatically fix the problem by moving the sub-task/child tickets above or below each other in their queue to match their parent's relative positions, see screenshot above.
    142144
    143145==== Project Rollup Analysis
    … …  
    172174}}}
    173175
    174 In the example above, the project's:
     176In the example above the project's:
    175177   
    176178 * {{{effort}}} field sums all of its children numeric values
    … …  
    181183In brief, the pivot algorithm is as follows (using the option's index):
    182184   
    183  * if all values are < the pivot value, then select their max value
    184  * else if all are > the pivot value, then select their min value
     185 * if all values are smaller than the pivot value, then select their maximum value
     186 * else if all are larger than the pivot value, then select their minimum value
    185187 * else select the pivot value
    186188
    187 Detected changes to rollup field values are shown with an option to automatically update the value - see screenshot above.
     189Detected changes to rollup field values are shown with an option to automatically update the value, see screenshot above.
    188190
    189191== Tips and hints
    190192
    191193A few ideas to optimize your analysis experience:
    192  * If this tool's ticket changes generate emails that are of little value to your team, then you can quiet them by enabling "Quiet Mode" using the [wiki:QuietPlugin Quiet Plugin].
     194 * If this tool's ticket changes generate emails that are of little value to your team, then you can suppress them by enabling "Quiet Mode" using the QuietPlugin.
    193195 * Use !TicketQuery in a project/epic's description to see all of its sub-tasks/children. Here is an example that allows you to order by position as the first column and the ticket id as the second. The {{{1234}}} is the project/epic's ticket number:
    194196 {{{