default of estimation_field should be 'remaininghours' instead of 'estimatedhours'

[falkb]

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...

[Adrian Fritz]

osimons, this also worth as general compatibility. Question: TimingAndEstimationPlugin its a bit older than this one and then takes precedence - could be that a criteria to choose which one could decline to be adaped? Question 2: how about backward compatibility (care taken though documentation)? I'm available for extra tests after into trunk.

[]'s

Adrián

[osimons]

I don't use the other plugins mentioned, but I do know that many users of the plugin have other means of estimating tasks than 'hours'. I would actually prefer that the default name for the field was just 'remaining' to make it general for hours, points or whatever estimation system is used.

I agree that it makes sense to align naming conventions. Still, unlike the other plugins this plugin supports configurable field naming so changing the default field name is quite trivial. I can't change naming for existing projects, but projects are free to change that themselves as falkb did - also taking care to update any reports, queries and query links that may reference the field.

[anonymous]

Is the most common use case for users who are interested in ticket statistics/scheduling that they install a few of ​those plugins and expect them to work together seamlessly from scratch? If yes, the best is to use same default values. That would make new installations more easy, in spite of this a reconfiguring is always tricky. Although if the fraction of 'hours' is just a minority, I don't know how to remedy the inconsistency...