[Trac] Ticket #1005: Implemented work hour reporting for tick ets

[Felix Collins]

>  > some additions to the types of custom fields to support
>  > Numerics - read
>  > only, cumulative, read/write etc. And enforcing of numeric
>  > only input.
>  > I looked into doing this myself but I wasn't quite confident of
>  > understanding trac enough to do it.
> So in your current version you need to "cumulate" the actual work yourself.
> This was the thing I wanted to avoid.

Yeah, I wanted to avoid this sort of thing too.  Luckily we have a small 
team of highly skilled developers so it is not to difficult to enforce 
conventions in the use of the system.  I would prefer the system to 
enforce the business logic.

> 
> @Christopher: What do you think about a patch that adds support for 
> cumulative / numeric
> custom fields? Would you apply such patch? Maybe for trac 0.9?
Please say yes... please say yes!  ;-)  It wouldn't be a major change to 
Trac after all.  It would simply mean extending an already existing 
mechanism.  It would be a backward and forward compatible change that 
would introduce no new dependencies.

While we are at it we could provide support for currency fields 
(including support for specifying the symbol in the ini file) and date 
fields (smart fields that supports entry in multiple formats and detects 
the format used?).  Anyone think of anything else useful?

The "cumulative" field could be implemented as a general "operation" 
field where the operation to be performed on the existing data could be 
specified in the ini file.

The ini file entry for the numeric fields could include specification of 
the precision, read/write status and radix. Trac could enforce this when 
numbers are entered.

I propose the following:

write once - field is only editable when the ticket is created (this 
could be useful for text fields too.

read only - for fields where the value is generated some external way

read write - fully editable field

operation - field is not writable directly but can be modified by way of 
a math. operation (specified in the ini file)

I propose storing it all as strings as I think that is what SQLite does 
anyway. Trac would convert it to strings and simply ignore values in the 
DB that didn't convert back to number correctly.

What about my idea of making the Roadmap page customisable in the same 
way that the ticket reports are?  Any comments?

Regards,
Felix