|Version 5 (modified by 5 years ago) (diff),|
Analyzes tickets for dependency and other problems
Notice: This plugin is unmaintained and available for adoption.
This is an extensible analysis tool for analyzing tickets in reports. The plugin currently has three built-in analyses:
- Milestone Dependency Analysis - ensures dependent tickets are in current or prior milestones
- Queue Dependency Analysis - ensures dependent tickets in a queue are ordered correctly
- Project Dependency Analysis - ensures dependent child tickets in a queue are ordered correctly
- Install the plugin (after downloading and unzipping):
cd analyzeplugin/0.12 sudo python setup.py bdist_egg sudo cp dist/TracAnalyze*.egg /your/trac/location/plugins/
See TracPlugins for more installation details and options. You'll likely need to restart Trac's web server after installation.
- Enable the plugin:
[components] analyze.* = enabled
You can alternatively use the Trac Web Admin GUI to enable any or all rules.
- Enable the
ANALYZE_VIEWpermission for those users who are allowed to execute analyses.
See the examples section below for how to specify rules.
If you have any issues, create a new ticket.
Download the zipped source from [download:analyzeplugin here].
This plugin currently includes three analyses that can each be individually enabled for one or more reports. Each analysis is configured by modifying the
[analyze] section of
trac.ini - see below for examples. When an analysis is enabled for a report, an "Analyze..." button appears at the top of the report and the analysis' name will appear in the subsequent dialog box when the button is clicked. You can either choose a single analysis or all analyses in this dialog box. Selecting "All" will run them serially.
Milestone Dependency Analysis
The popular 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.
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). This works with either semantics for blockedby tickets:
- blockedby tickets are peer ordering relationships
- blockedby tickets are project (aka parent-child) relationships) - where the parent/project's milestone is the latest milestone for the work to be completed
To enable this analysis for a given report, list those reports in
trac.ini as follows:
[analyze] milestone_reports = 1,9
Detected problems are shown with an option to automatically fix the problem by moving tickets into appropriate milestones.
Queue Dependency Analysis
The 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.
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:
[analyze] queue_reports = 2,9 queue_fields = queue,milestone
queue_fields option above tells this analysis what fields define a queue. Queues can be defined by one 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:
[analyze] queue_fields.9 = queue
In this example, report 2 uses both
milestone fields to define a queue whereas report 9 uses only the
Detected problems are shown with an option to automatically fix the problem by moving tickets above or below each other in the queue.
Project Dependency Analysis
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 Dependency Analysis comes in.
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:
[analyze] project_reports = 19 project_type = epic
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.
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 the queue (to map their parent's relative positions).
A few ideas to optimize your analysis experience:
- 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 Quiet Plugin.
- 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:
Extensibility (implementation details)
Each analysis is implemented as a Trac extension point to allow for new analyses to be added fairly easily. See analysis.py for the
IAnalysis interface. In brief, you only need to define two methods for each analysis:
can_analyze(self, report)- returns
Trueif this analysis can analyze the given report
get_solutions(self, db, request args)- return a dict of
datafields, or a list of these that define how to fix the detected issue.
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:
fix_issue(self, db, data, author)- fix the issue using the data that was returned earlier from
See the code for examples and other smaller tweaks to the
OAnalysis interface and base