Sort numeric columns as numbers, not strings

[chris.nelson.1022@…]

Custom fields don't have a numeric option so when sorting by fields that contain numeric values (like estimatedhours from Timing and Estimation Plugin), you get orders like:

0.0, 1.0, 12.0, 120.0, 16.0, 2.0, 20.0, …

By adding these fields to the numeric_columns setting in trac.ini

[query]
numeric_columns = totalhours, estimatedhours, remaininghours

the ticket queries and reports sort properly.

[Chris.Nelson@…]

Patch to implement numeric_columns query option.

[Ryan J Ollos <ryan.j.ollos@…>]

It looks like a useful feature.

Did you considered solving this by adding a new field type to TracTicketsCustomFields, or adding an option to the text field type to have the value interpreted as numeric? Maybe format = numeric?

I think your patch could be pretty much the same as it is now, except that you'd create the self.numeric_columns list by iterating over the list of dictionaries in self.fields.

One way or another, it seems desirable to directly associate the information in your numeric_columns configuration option with the custom fields configuration options.

[Chris.Nelson@…]

Replying to Ryan J Ollos <ryan.j.ollos@…>:

It looks like a useful feature.

Thanks.

Did you considered solving this by adding a new field type to TracTicketsCustomFields, or adding an option to the text field type to have the value interpreted as numeric? Maybe format = numeric?

No. I'm not that smart. ;-) The basic structure of this patch is a year or two old. We knew Trac internals less well then (we understand them fairly poorly even now) and didn't, necessarily, make good architectural decisions.

I think your patch could be pretty much the same as it is now, except that you'd create the self.numeric_columns list by iterating over the list of dictionaries in self.fields.

One way or another, it seems desirable to directly associate the information in your numeric_columns configuration option with the custom fields configuration options.

But how many other places would I have to touch that make text-oriented assumptions about custom fields?

[Ryan J Ollos <ryan.j.ollos@…>]

Replying to Chris.Nelson@…:

But how many other places would I have to touch that make text-oriented assumptions about custom fields?

Yeah, good point. I suppose the values would continue to be stored in the database as text, and we'd want to do a cast in _fetch_ticket​.

[Steffen Hoffmann]

relate this ticket by keyword, i.e. to pages like FieldRefactoring

Note, that #3080 already requested numeric fields for implementing an ordering schema other than text.

[Ryan J Ollos]

Replying to Ryan J Ollos <ryan.j.ollos@…>:

Did you considered solving this by adding a new field type to TracTicketsCustomFields, or adding an option to the text field type to have the value interpreted as numeric? Maybe format = numeric?

#10040 implements this approach, so closing as a duplicate of that ticket.