ticket,summary,type,release,owner,status,created,modified,_description,_reporter 10915,Configuration to use TimingAndEstimationPlugin fields,enhancement,1.0,Joachim Hoessler,new,2013-03-08T10:13:18+01:00,2013-03-08T10:13:18+01:00,It would be nice if we could reuse the time fields given by the TimingAndEstimationPlugin.,paolo@… 8681,default of estimation_field should be 'remaininghours' instead of 'estimatedhours',enhancement,0.12,osimons,new,2011-04-07T12:33:17+02:00,2020-05-01T06:51:13+02:00,"This change will ensure compatibility to TimingAndEstimationPlugin as well as to TracJsGanttPlugin. Those Trac plugins use 'estimatedhours' in the meaning of 'originally planned', and 'remaininghours' in the meaning of 'currently still expected hours'. EstimationToolsPlugin always works in the meaning of tracking the 'currently still expected hours' but uses 'estimatedhours' for it. This clashes with the other plugins. It should also use 'remaininghours' as internal default if {{{ [estimation-tools] estimation_field = 'remaininghours' }}} is not set in trac.ini. I fell into this trap and 1. had to set {{{ estimation_field = 'remaininghours' }}} 2. and also had to directly tweak the database this way: {{{ UPDATE ticket_change SET field='remaininghours' WHERE field = 'estimatedhours' UPDATE ticket_custom SET name='remaininghours' WHERE name = 'estimatedhours' }}} The whole thing is reasoned in a missing mandatory overall-Trac naming convention concerning to such ticket fields. This probably should go into an extra new ticket...",falkb 8840,Overcome dependency to google charts (internet and data max. size limitations),enhancement,0.12,Joachim Hoessler,new,2011-05-27T08:39:44+02:00,2020-05-01T06:51:13+02:00,"This could be the alternative: http://www.jscharts.com/ Look at TracJsGanttPlugin, they also use such Java Script stuff...",falkb 9084,missing burndown chart,defect,0.12,Joachim Hoessler,new,2011-08-11T17:55:04+02:00,2011-08-25T10:33:12+02:00,"i just moved my trac installation to a different machine and am having problems with the burndown chart display This fails gives me a broken link: {{{ [[BurndownChart(milestone=Customer Deployment, startdate=2011-01-19)]] }}} But this works fine: {{{ [[WorkloadChart(milestone=Customer Deployment, width=800, height=200)]] }}} Is there something else i need to do here",smcbutler 9165,Allow estimation_field to be set as Macro attribute,enhancement,0.12,Joachim Hoessler,new,2011-09-08T21:03:55+02:00,2020-05-01T06:51:13+02:00,"Some developers using the agile approach would like to use more than one burndown chart. It makes for example sense to have one burndown chart showing »remaining hours« and one showing »not finished story points«. What do you think about allowing the calculation-field to be passed in as macro parameter? Example: {{{ [[BurndownChart(title=Burndown Chart, milestone=Beta 2, startdate=2011-09-07, estimation_field=storypoints)]] }}} Would create a chart based on the field storypoints. When not specified it should use the field from trac.ini. I achieved this behaviour by adding this snippet to the macro functions: {{{ estimation_field = self.estimation_field if (options['estimation_field'] != self.estimation_field): estimation_field = options['estimation_field'] }}} Additionally I replaced every {{{self.estimation_field}}} with {{{estimation_field}}} in subsequent lines. This is an example diff for the file trunk/estimationtools/burndownchart.py: {{{ 13c13 < 'bgcolor': 'ffffff00', 'wecolor':'ccccccaa', 'colorexpected': 'ffddaa', 'weekends':'true', 'gridlines' : '0'} --- > 'bgcolor': 'ffffff00', 'wecolor':'ccccccaa', 'colorexpected': 'ffddaa', 'weekends':'true', 'gridlines' : '0', 'estimation_field' : 'remaininghours'} 60a61,64 > > estimation_field = self.estimation_field > if (options['estimation_field'] != 'remaininghours'): > estimation_field = options['estimation_field'] 146a151,154 > estimation_field = self.estimation_field > if (options['estimation_field'] != 'remaininghours'): > estimation_field = options['estimation_field'] > 157c165 < query_args[self.estimation_field + ""!""] = None --- > query_args[estimation_field + ""!""] = None 169c177 < latest_estimate = self._cast_estimate(t[self.estimation_field]) --- > latest_estimate = self._cast_estimate(t[estimation_field]) 179c187 < ""ORDER BY c.time ASC"", [t['id'], self.estimation_field]) --- > ""ORDER BY c.time ASC"", [t['id'], estimation_field]) 195c203 < if row_field == self.estimation_field: --- > if row_field == estimation_field: }}} utils.py {{{ 21c21 < 'expected', 'colorexpected', 'title'] --- > 'expected', 'colorexpected', 'title', 'estimation_field'] }}} My python knowledge is quite limited so please improve the code where necessary.",asyn 9771,burndown chart query returns 0 rows when milestone has a ':' in it.,defect,0.12,osimons,new,2012-02-06T15:35:34+01:00,2020-05-01T06:51:13+02:00,"When a milestone has a ':' in the name, the query used by the burndown chart escapes it and the query does not return any values.",jcole@… 4044,Working with trac hours multi-project query?,enhancement,0.11,Joachim Hoessler,new,2008-11-06T23:37:51+01:00,2008-12-12T18:07:08+01:00,"Hi, First off, love your plugin. I do have a question, what do you think it would take to make this work with the TracHours plugin multi-project query in addition to the default trac query? Specifically I am looking at the WorkLoad graph. I guess ideally it would be nice to break it down somehow by project (maybe on click, or shading of the colors within a single user?), but that is above and beyond what I am after at the moment? again, thanks for the nice plugin!",Jay 3876,Compact Format for Burndown,enhancement,0.11,Adrian Fritz,new,2008-10-09T19:44:06+02:00,2011-05-10T07:46:41+02:00,"I like to use the BurndownChart macro in the descriptions of milestones, so that the Roadmap view shows the charts below the progress bars. The current format consumes unnecessary vertical space for the milestone title and month/year labels on the time axis. I'd like an option (compact = true) that suppresses the title and renders month and year on the same line, like ""Dec 08"" or ""12/08"".",peter@… 4669,Tickets removed from milestone are not reflected in burndown chart,defect,0.11,Joachim Hoessler,assigned,2009-02-20T02:24:22+01:00,2010-07-27T21:32:06+02:00,"In the common scenario that some tickets are moved out of a milestone during the course of that milestone, the burndown chart does not reflect historically-accurate information. This is caused by the burndownchart.py _calculate_timetable method, which only considers tickets that are currently assigned to the milestone in question. Any ticket which is assigned to another milestone _at this moment_ is not considered when computing the chart's values. This ignores all tickets that used to be part of the milestone but have now been moved. To find these tickets for each day, you can use a query like this, where $milestone$, $midnightBefore$, and $midnightAfter$ are the appropriate values: select * from ticket_change where field = 'milestone' and oldvalue = $milestone$ and time >= $midnightBefore$ and time < $midnightAfter$;",peter@… 4752,Add range options to graph for burndowns,enhancement,0.11,osimons,new,2009-03-05T21:42:16+01:00,2011-05-10T07:14:58+02:00,"We commonly use burndown charts internally to show the status of our project week to week. It would be VERY useful to specify that you want the running range to be 1 week, and have the chart show the week previous up to the current date.",mgesner@… 5593,Problems for burndown-chart for multiple milestone,defect,0.11,Joachim Hoessler,new,2009-07-30T17:22:16+02:00,2009-08-12T21:37:07+02:00,"First: Thanks for this - works very good for us! Then From the examples, I learned that one should be able to say: BurndownChart(milestone=PG|38, startdate=2009-06-07) But this for me produces: Error: Macro BurndownChart(milestone=PG|38, startdate=2009-06-07) failed status",Jörg Viola 6186,Possibility to create Burndown chart with mutiple lines,enhancement,0.11,osimons,new,2009-11-10T19:44:33+01:00,2011-09-02T14:38:50+02:00," Hello, In my company we are trying to use EstimationToolsPlugin - it's working, but we would like to have the possibility to diferenciate tickets by ticket_type attribute. We have a specific type of ticket that represents unplanned activities, and I would like to represent them on another line, just like the following image: [[Image(http://lh4.ggpht.com/_zS5xn0A5mXo/Sk46DLXR_fI/AAAAAAAAACI/t2K4oQEfKF8/chart_thumb%5B1%5D.jpg)]] Link: http://lh4.ggpht.com/_zS5xn0A5mXo/Sk46DLXR_fI/AAAAAAAAACI/t2K4oQEfKF8/chart_thumb%5B1%5D.jpg One way to represent that would be adding an attribute line_attribute to the burndown line setup: {{{ [[BurndownChart(milestone=Sprint 045, startdate=2009-11-01, enddate=2009-11-13, planned_ticket_type=Bug|Enhancement|Task, unplanned_ticket_type=Unplanned)]] }}} Hope that u consider this feature request. Thank you",victorhg@… 6843,Rendering a trend line,enhancement,0.11,Joachim Hoessler,new,2010-03-22T17:15:27+01:00,2010-03-22T17:16:07+01:00,"Great plugin! This is a feature suggestion: I've seen on some burndown graphs a trend line, which I find particularly useful. It gives an idea of when will the spring finish it the team maintains its speed. Here's an example of a trend line, rendered by the Agile for Scrum plugin: http://www.userstories.com/system/product_image/0000/0400/Agilo_for_Scrum_Open_Source_Scrum_Tool.jpg",Filipe Correia 9016,Macro to show number of hours left until a milestone's due date,enhancement,0.11,Joachim Hoessler,new,2011-07-23T00:32:03+02:00,2011-07-23T00:32:03+02:00,"I'm starting work on writing a small macro to show the number of work hours left until a specified due date. The macro will take a milestone as an argument and use the milestone's due date as a data source, or take a date string as an argument. In its initial form, it would treat each day as an 8 hour workday, each week as a 5 day work week and not take holidays into account. These limitation lead to some obvious ways to extend the macro. My intent is to provide a useful complement to the `RemainingHours` macro. One could put something like the following in a wiki page by using both macros: Remaining effort to conclude this milestone: '''64''' hrs. [[BR]] Remaining work hours until this milestone's due date: '''46.3''' hrs. My initial plan is to name the macro `RemainingWorkHours`. I'm seeking feedback on how to best implement this (i.e. what is the best name for the macro?, should this new macro just be part of the `RemainingHours` macro by extending that macro with additional arguments?), and whether it might be considered for inclusion in the EstimationToolsPlugin. Thanks!",Ryan J Ollos 11778,How do you invoke tests?,enhancement,0.11,Joachim Hoessler,new,2014-05-27T19:42:02+02:00,2014-05-28T23:15:22+02:00,"I want to be sure some changes I've made haven't broken anything (and, perhaps, add tests for those changes/additions) but I can't figure out how to invoke the tests. {{{ ~/src/trac/plugins/estimationtoolsplugin/estimationtools$ ls burndownchart.py htdocs tests hoursinplaceeditor.py __init__.py utils.py hoursremaining.py templates workloadchart.py ~/src/trac/plugins/estimationtoolsplugin/estimationtools$ sudo python tests/burndownchart.py Traceback (most recent call last): File ""tests/burndownchart.py"", line 3, in from estimationtools.burndownchart import BurndownChart ImportError: No module named estimationtools.burndownchart ~/src/trac/plugins/estimationtoolsplugin/estimationtools$ cd tests/ ~/src/trac/plugins/estimationtoolsplugin/estimationtools/tests$ sudo python burndownchart.py Traceback (most recent call last): File ""burndownchart.py"", line 3, in from estimationtools.burndownchart import BurndownChart ImportError: No module named estimationtools.burndownchart }}} ",Chris Nelson 4131,Show unexpected activities in burdown charts,enhancement,0.10,Joachim Hoessler,new,2008-11-20T11:26:42+01:00,2011-04-15T10:34:35+02:00,"Hi, it would be nice to tag unexpected activities in the burndown chart, such as changing the content of the current sprint after an emergency meeting. Some word about motivation/background for this enhancement. If you use the burndown chart as a planing help it has one known weakness. Just from looking at it you can not differentiate if a spike is caused by team updates (to adjust planning to reality) OR if it is caused by an unexpected external event (critical bug needs to be handled). Such events are rare, but they happen more often in the first sprints or when a company is new to agile processes. My suggestion is to tag tickets with unexpected events (after the team decided it can not push them to next sprint) and show them as dots in the burnddown chart. Here is how it could look like: [http://chart.apis.google.com/chart?chs=450x200&cht=lxy&chd=t:0,10,20,30,40,50,70|100,90,84,70,60,70,50&chco=ff0000&chm=d,ff0000,0,5,10|tUnexpected+items+added,000000,0,5,10 http://chart.apis.google.com... example image] Hope you like the idea, M",anonymous 4217,Pass thru parameters to Google,enhancement,0.10,Joachim Hoessler,new,2008-12-05T12:10:16+01:00,2009-01-28T08:08:34+01:00,"Nice plugin It would be very useful to be able to pass though any unrecognized/raw parameters to the Google image generation URL to take advantage of additional features. Something like: {{{ [[BurndownChart(milestone=Sprint 1, startdate=2008-12-05, raw=|tUnexpected+items+added,000000,0,5,10|) }}} would provide an interim solution to #4131",metafeather 11739,EstimationTools plug-in for planned and total hours,enhancement,,Joachim Hoessler,new,2014-05-08T12:11:04+02:00,2014-05-09T12:36:06+02:00,"Finnish Alfame Systems Oy has made some improvements to the EstimationToolsPlugin. The Alfame version of the plug-in counts planned (new PlannedHours macro) and total hours (new TotalHours macro) in the same way as the original version counts estimated hours (existing HoursRemaining macro). However if the page to be included contains any non-ASCII characters, such as the common Finnish vowels ä or ö, the processing might stop with error. The fix to this is however a one-liner: {{{#!diff -return str(body)+(edit_link and link_tag or '') +return unicode(body)+(edit_link and link_tag or '') }}} Attached is the diff / patch for the improved version.",anonymous 12503,Display hours spent in chart,enhancement,,Joachim Hoessler,new,2015-09-03T12:08:41+02:00,2015-09-03T12:08:41+02:00,Proposed patch to add hours spent.,anonymous