Changes between Version 2 and Version 3 of AnalyzePlugin


Ignore:
Timestamp:
Dec 11, 2011, 1:12:07 AM (12 years ago)
Author:
Rob Guttman
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • AnalyzePlugin

    v2 v3  
    5959The popular [wiki:MasterTicketsPlugin master tickets plugin] enables specifying dependencies amongst tickets and visualizes them via graphviz.  However, it does not provide tools to help manage these dependencies including detecting when they're not scheduled in the correct dependency order.  That's where this Milestone Dependency Analysis comes in.
    6060
    61 This analysis detects when a ticket in a given report has a dependency (a "blockedby" ticket) that is in a future milestone (or not scheduled in any milestone).  To enable this analysis for a given report, list those reports in {{{trac.ini}}} as follows:
     61This analysis detects when a ticket in a given report has a dependency (a "blockedby" ticket) that is in a future milestone (or not scheduled in any milestone).  This works with either semantics for blockedby tickets:
     62
     63 * blockedby tickets are ''peer'' ordering relationships
     64 * blockedby tickets are ''project (aka parent-child) relationships)'' - where the parent/project's milestone is the latest milestone for the work to be completed
     65
     66To enable this analysis for a given report, list those reports in {{{trac.ini}}} as follows:
    6267{{{
    6368[analyze]
     
    6873
    6974==== Queue Dependency Analysis ====
    70 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 custom field usually named {{{position}}} (but can be named anything).  Dependencies amongst tickets in a queue have similar problems as tickets across milestones - in this case, a dependent ticket should precede (i.e., appear higher in the queue which means have a lower {{{position}}} value), but it can be difficult to manuually catch all of these dependency violations.  That's where this Queue Dependency Analysis comes in.
     75The [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 (i.e., 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.
    7176
    72 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).  To enable this analysis for a given report, list those reports in {{{trac.ini}}} as follows:
     77This 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).  To enable this analysis for a given report, list those reports in {{{trac.ini}}} as follows:
    7378{{{
    7479[analyze]
     
    8792Detected problems are shown with an option to automatically fix the problem by moving tickets above or below each other in the queue.
    8893
     94==== Project Dependency Analysis ====
     95This 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 Dependency Analysis comes in.
     96
     97This 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:
     98{{{
     99[analyze]
     100project_reports = 19
     101project_type = epic
     102}}}
     103
     104The {{{project_type}}} option above is the name that you call your projects (e.g., "epic" (the default), "project", etc.).  These tickets do not have to be of any specific ticket type - at least not at this time.
     105
     106Detected problems are shown with an option to automatically fix the problem by moving the sub-task/child tickets above or below each other in the queue (to map their parent's relative positions).
     107
    89108== Tips! ==
     109A few ideas to optimize your analysis experience:
    90110 * If this tool's project management changes generates emails that are of little value to your team, then you can quiet them by enabling "Quiet Mode" using the [wiki:QuietPlugin Quiet Plugin].
     111 * Use !TicketQuery in a project/epic's description to see all of its sub-tasks/children.  Here's an example that allows you to order by position as the first column and the ticket id as the second:
     112 {{{
     113 [[TicketQuery(blocking~=1364,format=table,col=position|id|summary|severity|owner|effort|milestone|phase,order=position,group=type)]]
     114 }}}
     115
     116== Extensibility (implementation details) ==
     117Each analysis is implemented as a Trac extension point to allow for new analyses to be added fairly easily.  See [browser:analyzeplugin/0.12/analyze/analysis.py analysis.py] for the {{{IAnalysis}}} interface.  In brief, you only need to define two methods for each analysis:
     118
     119 * {{{can_analyze(self, report)}}} - returns {{{True}}} if this analysis can analyze the given report
     120 * {{{get_solutions(self, db, request args)}}} - return a dict of {{{name}}} and {{{data}}} fields, or a list of these that define how to fix the detected issue.
     121
     122where {{{data}}} is any serializable (to JSON) python object that contains all of the data needed to automatically fix the problem.  If this {{{data}}} object is a dict of ticket fields and their new values (or a list of these), then the default {{{fix_issue()}}} method will automatically apply the fix upon user command.  If your fix is more involved, you can override this method:
     123
     124 * {{{fix_issue(self, db, data, author)}}} - fix the issue using the data that was returned earlier from {{{get_solutions()}}}.
     125
     126See the code for examples and other smaller tweaks to the {{{OAnalysis}}} interface and base {{{Analysis}}} class.
    91127
    92128== Recent Changes ==